Help with building GNU Radio for Android

GNU Radio
1

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
2

On Mon, Aug 17, 2015 at 7:28 PM, Schuyler St. Leger <
[email protected]> 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

3

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

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

4

On Fri, Aug 21, 2015 at 9:20 AM, devin kelly [email protected] wrote:

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

5

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.