# Help with building GNU Radio for Android **URL:** \ **Category:** GNU Radio\ **Created:** [August 18, 2015, 3:04pm UTC](https://www.ruby-forum.com/t/help-with-building-gnu-radio-for-android/243053 "2015-08-18T15:04:14Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [August 18, 2015, 3:04pm UTC](https://www.ruby-forum.com/t/help-with-building-gnu-radio-for-android/243053/1 "2015-08-18T15:04:14Z")
I am trying to build GNU Radio for Android and am having issues with the build process. I first tried building GNU Radio for Android on Mac OS X 10.10.4. I was able to follow the directions successfully until I had to build gr-grand. When I tried to build gr-grand I got this error (see error 1). I have tried searching for this error, but have not found any useful information from my search. I am not sure if this is an error with the build procedure, or if it is an error with the Android NDK and Python. I then tried building GNU Radio for Android in a Ubuntu 14.04 64 bit VM, but when trying to stage Boost (./b2) I get this output from Boost (see error 2) and get an error about -march=armv7-m not being a supported compiler flag when Boost starts compiling. I have tried adding the toolset=gcc-android to Boost but this did not fix the problem (I had to do this on Mac to get Boost to use the configuration in the user-config.jam file). I would like help getting this working, as I really want to get GNU Radio working on Android for me. Schuyler St. Leger Error 1: [80%] Building CXX object swig/CMakeFiles/\_grand\_swig.dir/grand\_swigPYTHON\_wrap.cxx.o In file included from /opt/android-toolchain/include/python2.7/Python.h:58:0, from /opt/grandroid/gr-grand/build/swig/grand\_swigPYTHON\_wrap.cxx:167: /opt/android-toolchain/include/python2.7/pyport.h:1029:2: error: #error “LONG\_BIT definition appears wrong for platform (bad gcc/glibc config?).” #error “LONG\_BIT definition appears wrong for platform (bad gcc/glibc config?).” ^ make[2]: \*\*\* [swig/CMakeFiles/\_grand\_swig.dir/grand\_swigPYTHON\_wrap.cxx.o] Error 1 make[1]: \*\*\* [swig/CMakeFiles/\_grand\_swig.dir/all] Error 2 make: \*\*\* [all] Error 2 Error 2: Performing configuration checks ``` - 32-bit : no - 64-bit : no - arm : no - mips1 : no - power : no - sparc : no - x86 : no - combined : no - has_icu builds : no - lockfree boost::atomic_flag : no ``` ---
**Author:** ![Schuyler\_StSLeger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@Schuyler\_StSLeger](https://www.ruby-forum.com/u/Schuyler_StSLeger)\ **Post date:** [August 21, 2015, 2:11am UTC](https://www.ruby-forum.com/t/help-with-building-gnu-radio-for-android/243053/2 "2015-08-21T02:11:27Z")
On Mon, Aug 17, 2015 at 7:28 PM, Schuyler St. Leger \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> wrote: > I am trying to build GNU Radio for Android and am having issues with the > build process. > > I first tried building GNU Radio for Android on Mac OS X 10.10.4. I was > able to follow the directions successfully until I had to build gr-grand. > When I tried to build gr-grand I got this error (see error 1). I have tried > searching for this error, but have not found any useful information from my > search. I am not sure if this is an error with the build procedure, or if > it is an error with the Android NDK and Python. We’ll have to spend some time looking into this. Most of use working on the Android stuff are using Linux – generally Ubuntu, either 14.04 or 15.04 (I use both versions, depending on which machine I’m on). This could be a conflict with the installed Python and the one in the SDK, or possibly just a bug in the SDK. Although, now that I think about it, there’s no reason to SWIG gr-grand. You’ll never use that in Python on Android; we only use the c++ library out, and specifically the static libgnuradio-grand.a library. Maybe try adding the flag -DENABLE\_PYTHON=False to the cmake line? > I then tried building GNU Radio for Android in a Ubuntu 14.04 64 bit VM, > but when trying to stage Boost (./b2) I get this output from Boost (see > error 2) and get an error about -march=armv7-m not being a supported > compiler flag when Boost starts compiling. I have tried adding the > toolset=gcc-android to Boost but this did not fix the problem (I had to > do this on Mac to get Boost to use the configuration in the user-config.jam > file). Are you sure you want armv7-m? Most of what we’re using is armv7-a. But you might just try “armv7” instead to use a more generic v7 architecture. Take a look at the gcc man page for a list of supported machines. This might be something you’ll need to play around with. > ``` > from > > - combined : no > - has_icu builds : no > - lockfree boost::atomic_flag : no > > ``` Yeah, when this is right, you should see ‘yes’ for 32-bit and arm. FYI, I should be getting a 64-bit ARM soon and will see what changes are necessary there. And if any of this helps and you do get it working, we should try to update the Android wiki page accordingly, either by fixing some of the instructions or with some side notes for these problems. Tom ---
**Author:** ![Schuyler\_StSLeger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@Schuyler\_StSLeger](https://www.ruby-forum.com/u/Schuyler_StSLeger)\ **Post date:** [August 21, 2015, 3:21pm UTC](https://www.ruby-forum.com/t/help-with-building-gnu-radio-for-android/243053/3 "2015-08-21T15:21:56Z")
I found the section of code the python NDK is complaining about: #ifndef LONG\_BIT #define LONG\_BIT (8 \* SIZEOF\_LONG) #endif #if LONG\_BIT != 8 \* SIZEOF\_LONG /\* 04-Oct-2000 LONG\_BIT is apparently (mis)defined as 64 on some recent - 32-bit platforms using gcc. We try to catch that here at compile-time - rather than waiting for integer multiplication to trigger bogus - overflows. \*/ #error “LONG\_BIT definition appears wrong for platform (bad gcc/glibc config?).” #endif So it looks like maybe SIZEOF\_LONG is what’s really not properly defined. I then found this python mailing list post: [https://mail.python.org/pipermail/python-bugs-list/2004-November/026111.html](https://mail.python.org/pipermail/python-bugs-list/2004-November/026111.html) The first poster says that this will limit python to only using glibc systems, which makes total sense here given that Android uses bionic not glibc. What I don’t understand is that bionic seems to define LONG\_BIT, SIZEOF\_LONG etc correctly: > So what’s it complaining about? Devin ---
**Author:** ![Schuyler\_StSLeger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@Schuyler\_StSLeger](https://www.ruby-forum.com/u/Schuyler_StSLeger)\ **Post date:** [August 21, 2015, 3:42pm UTC](https://www.ruby-forum.com/t/help-with-building-gnu-radio-for-android/243053/4 "2015-08-21T15:42:23Z")
On Fri, Aug 21, 2015 at 9:20 AM, devin kelly [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > - overflows. > [[python-Bugs-1023838] Include/pyport.h: Bad LONG\_BIT assumption on non-glibc sys](https://mail.python.org/pipermail/python-bugs-list/2004-November/026111.html) > > Devin Thanks for that, Devin. I’m still not sure what’s going wrong, but I wanted to say that, yes, our model for Android is to try to stay as well within the standard Android system and tools as possible, including using bionic and not an external C library. However, we are also using the GCC libstdc++ that comes with the SDKs. Schuyler, there might have been a change in something in Android (they really don’t care about changing things between versions) when building the standalone SDK. Take a look at the options you passed when building that part of the project. Also, make sure you are using GCC 4.8 and NOT 4.9. We have other issues with 4.9. Tom ---
**Author:** ![Schuyler\_StSLeger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/65b543/32.png) [@Schuyler\_StSLeger](https://www.ruby-forum.com/u/Schuyler_StSLeger)\ **Post date:** [August 21, 2015, 9:42pm UTC](https://www.ruby-forum.com/t/help-with-building-gnu-radio-for-android/243053/5 "2015-08-21T21:42:50Z")
> Although, now that I think about it, there’s no reason to SWIG gr-grand. > You’ll never use that in Python on Android; we only use the c++ library > out, and specifically the static libgnuradio-grand.a library. > > Maybe try adding the flag -DENABLE\_PYTHON=False to the cmake line? ENABLE\_PYTHON is not an available option, and there is no option to disable Python or SWIG (the cmake user settable variables can be listed using -LAH). Are you sure you want armv7-m? Most of what we’re using is armv7-a. But you > might just try “armv7” instead to use a more generic v7 architecture. Take > a look at the gcc man page for a list of supported machines. This might be > something you’ll need to play around with. I made a mistake in copying the error, here is the correct error. Assembler messages: Fatal error: invalid -march= option: `armv7-a’ I was able to get Boost to build. The problem is that when arm-linux-androideabi-g++ calls the assembler it looks in the path for as the problem with this is that the assembler for Android is named arm-linux-androideabi-as . To fix this I symlinked arm-linux-androideabi-as to as and android-toolchain/bin needs to be in your path (it should be from setting up the android toolchain). However this must be done after running bootstrap.sh or Boost will fail to build Boost.Build. Running hash -r may be required to get bash to find the correct assembler. The real problem here is that android-toolchain/arm-linux-androideabi/bin/ is empty and not symlinked to the tools in android-toolchain/bin/ like it normally is. I have tried rebuilding the toolchain multiple times, but it is not making the symlinks. I just copied the symlinks from OS X and it works on Ubuntu 14.04 (tested for FFTW). Yeah, when this is right, you should see ‘yes’ for 32-bit and arm. > That is what I got when using OS X with Boost and specifying toolset=gcc-android . How hard would it be to get fosphor working on Android? Schuyler, there might have been a change in something in Android (they > really don’t care about changing things between versions) when building the > standalone SDK. Take a look at the options you passed when building that > part of the project. Also, make sure you are using GCC 4.8 and NOT 4.9. We > have other issues with 4.9. I am using GCC 4.8.