The conflicting advice here is part of the problem here. All, I really wish we could stop providing conflicting advice to people that come asking for help on embedded builds. Native compile is not even an option if you plan to do actual development. Cross compile is difficult the first few times and may not be necessary.
Shaun, I'm going to dump a lot of text here that will hopefully guide you down a single path rather than receiving disparate information since I know you've been trying to get this working for a while.
Philip, and others interested in embedded workflows (embedded WG?): I suspect we need to rework the message on the embedded page to include people that have simpler ARM requirements. What follows is my first attempt at exposing a small collection of options that I think should be apparent on the embedded wiki.
Assuming the actual goal is to get GNU Radio + some flowgraph running on an ARM processor there are multiple ways to reach this point. The first step in all of them is to build GNU Radio with an ARM target. Here are the three best approaches:
* native compile where the target processor does the work
* cross compile where a different (probably x86_64) processor does all of the work
* use a package manager to install a binary
Following is a short list of some highlights of each method:
*** Cross compile
** Pros
* Compilation is faster
* development happens in your normal environment
** Cons
* Hard to get bootstrapped (need an SDK that targets your OS + all dependencies)
*** Native compile
** Pros
* intuitive as long as your embedded image comes with a C compiler and python
** Cons
* Compilation is very slow. Even on more capable quad core 2GHz+ ARMs an x86_64 cross build will still be much faster
* Usually low memory. The infamous out of memory manager will subtly kill your compiler, especially on swig
*** Package manager binary install
** Pros
* Fastest way to get GNU Radio
** Cons
* Stuck with whatever version is packaged for you
The route you take really depends on your needs. If you just need GNU Radio and you're tinkering with some flowgraphs then by all means use a binary install if it is available for your machine. If a binary isn't available then you need to compile from source. If you know you're only going to need to do this once then a native compile is acceptable, but you need to be aware of the trade offs you are making. You can get around the low memory problem by using SWAP which comes with its own problems (SD card wear out and its slower). If you expect to be doing any development on GNU Radio or an OOT module you are working on then it is probably worth the investment in getting bootstrapped with a cross compiler environment.
** Native compile
The native compile is mostly the same as doing a native compiler on x86_64. The primary difference is that it is harder for us to detect ARM features at configure time. The practical implication is that you need to provide some assistance to VOLK through cmake. This is where the CFLAGS and CXXFLAGS command line comes in. I honestly hate seeing people dump versions of their CFLAGS as if it were an authoritative source because this is the kind of thing that really needs to be determined by whoever is doing the build. The fact is you can't get away without knowing your -march settings on ARM. Once you get cmake working, make and make install away.
** Cross compile
Again there are several options. The core GNU Radio developers have a preference for using Open Embedded (OE) based systems and Tom provides a rootfs and SDK. Philip maintains the layers that provide GNU Radio support. If your board is supported by an OE layer then you can learn more about using OE on their website. It's a pretty nice tool. If your board is not supported by OE you can either: 1) add support (non-trivial for first timers), 2) use Tom's rootfs and chroot (I find this awkward, but some people like it), 3) use another method. If you want to cross compile GNU Radio with OE we have instructions on the wiki (source the OE SDK environment, point cmake at oe-sdk.cmake toolchain file, make && make install)
If you don't want to use OE there are still options. You may be able to get an SDK for your distribution. There's an unknown amount of work ahead of your with this route because of all of the GNU Radio dependencies. If the SDK does not include a dependency then you must build it. If you're inexperienced with this then I will let you in on a secret: GNU Radio is actually really easy to cross compile compared to many of our dependencies.
Finally there are hybrid solutions that I have heard of working that involve using distcc where the ARM dispatches work to a distcc node running on an x86_64 processor. I've never done this and don't have anything else to say about it.
** Conclusion
There is no one way to get GNU Radio on an ARM. The method you take depends on your needs and is a decision no one else can make for you. When people come to the list asking for a native compile on ARM we should stop telling them they have to cross compile. Similarly when people come to the list asking for a cross compile we need to stop telling them they should do a native compile.
Sorry this is long, but I think some edited form of it will be useful for the wiki.
Shaun, if you pick a route I think we can guide you towards a solution that works for you.
Cheers,
Nathan