Problem building GNURadio / osmo*

Discussions related to embedded firmware, driver, and user mode application software development
Post Reply
dongfang
Posts: 1
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?
Post Reply