Problem building GNURadio / osmo*

Discussions related to embedded firmware, driver, and user mode application software development
Post Reply
dongfang
Posts: 2
Joined: Thu Feb 19, 2026 4:13 am

Problem building GNURadio / osmo*

Post by dongfang »

Hi all,

I am trying to get my old bladeRF X40 going again, and trying to follow this: https://github.com/Nuand/bladeRF/wiki/G ... d%3A-Linux . I have Ubuntu 24.04.LTS, gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 .

At this step: pybombs prefix init ~/pybombs/bladeRF -a bladeRF -R gnuradio-default

I get a lot of:
/home/x/pybombs/bladeRF/include/volk/volk_common.h:182:23: error: exponent has no digits
182 | const float a1 = +0x1.ffffeap-1f;
| ^~~~~~~~~~~
/home/x/pybombs/bladeRF/include/volk/volk_common.h:183:23: error: exponent has no digits
183 | const float a3 = -0x1.55437p-2f;
| ^~~~~~~~~~
/home/x/pybombs/bladeRF/include/volk/volk_common.h:184:23: error: exponent has no digits
184 | const float a5 = +0x1.972be6p-3f;
| ^~~~~~~~~~~

I tried to find solutions the lazy way, but this seems not to be a FAQ. It seems GCC doesn't get the hexadecimal decimal literals in there, and it should be passed (?) a something to enable C++17. I don't know how to do that from within the pybombs stuff, can I use an environment variable?

Does somebody know how I can get past this problem?

Thanks a lot -

Kind regards, Soren
fnfunkin
Posts: 1
Joined: Tue Mar 17, 2026 9:31 pm

Re: Problem building GNURadio / osmo*

Post by fnfunkin »

I ran into something very similar when building older GNU Radio stacks with newer GCC. In my case it turned out not to be a C++17 issue, but a mismatch in compiler flags—those hex float literals are valid, but only if the file is being treated as C99/C++11+ correctly. I fixed it by forcing PyBOMBS to use -std=gnu11 (for C parts) via CFLAGS/CXXFLAGS before running pybombs, or by patching the build config to explicitly set the standard. fnf

If you’re new to this, it might help to check which files are being compiled as C vs C++—this error often pops up when a C file gets compiled with the wrong standard or flags.
Freyana
Posts: 1
Joined: Tue Apr 28, 2026 3:07 am

Re: Problem building GNURadio / osmo*

Post by Freyana »

dongfang wrote: Thu Feb 19, 2026 4:25 am Hi all,

I am trying to get my old bladeRF X40 going again, and trying to follow this: https://github.com/Nuand/bladeRF/wiki/G ... d%3A-Linux . I have Ubuntu 24.04.LTS, gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 .

At this step: pybombs prefix init ~/pybombs/bladeRF -a bladeRF -R gnuradio-default

I get a lot of:
/home/x/pybombs/bladeRF/include/volk/volk_common.h:182:23: error: exponent has no digits
182 | const float a1 = +0x1.ffffeap-1f;
| ^~~~~~~~~~~
/home/x/pybombs/bladeRF/include/volk/volk_common.h:183:23: error: exponent has no digits
183 | const float a3 = -0x1.55437p-2f;
| ^~~~~~~~~~
/home/x/pybombs/bladeRF/include/volk/volk_common.h:184:23: error: exponent has no digits
184 | const float a5 = +0x1.972be6p-3f;
| ^~~~~~~~~~~

I tried to find solutions the lazy way, but this seems not to be a FAQ. It seems GCC doesn't get the hexadecimal decimal literals in there, and it should be passed (?) a something to enable C++17. I don't know how to do that from within the pybombs stuff, can I use an environment variable?snow rider 3d

Does somebody know how I can get past this problem?

Thanks a lot -

Kind regards, Soren
What steps can I take to enable C++17 support in my GCC configuration while using pybombs, so that I can resolve the "exponent has no digits" error when compiling volk_common.h?
dongfang
Posts: 2
Joined: Thu Feb 19, 2026 4:13 am

Re: Problem building GNURadio / osmo*

Post by dongfang »

Hi all
Okay, I gave up waiting sorry.
Meanwhile, I have Claude, and he helped me.
It turned out I had to change

set(CMAKE_CXX_STANDARD 14)
to
set(CMAKE_CXX_STANDARD 17)

in ~/pybombs/bladeRF/src/gnuradio/CMakeLists.txt about line 135.

So far, that seems to have fixed it.. still building ... and it has compiled!

However it seems there are more problems at runtime. I just had Claude install the apt prebuilt stuff instead, at least it works w/o problems.

Kind regards, Soren
Post Reply