Cross-compiling to armhf/beaglebone black

[rsfairman]

The gist of my question is how to cross-compile from an i386 to ARM. It seems like different package installations are hiding previous installations, and the compiler can't find libraries, etc.

I want to cross compile from an i386 machine running Debian 8.7.1 to an ARM machine (a Beaglebone Black, also running Debian). The aim is to use CodeBlocks and wxWidgets with C++ on the i386 to write a GUI which will run on the BBB. Ideally, I want to compile and test entirely on the i386, then flip a few compiler switches to get a version that will run on the BBB once the code is "done" (and periodically during the development process). I'm not totally wed to using CodeBlocks or wxWidgets, though I have experience with both, and I don't think either of those is relevant to the problem I have.

I first installed build-essential, then CodeBlocks, and wxWidgets, and that went fine. All of the sample code that comes with wxWidgets compiled without a hitch and the programs run fine (and still run fine). Then I followed the directions at
http://exploringbeaglebone.com/chapter7/
for installing the packages to allow cross-compiling. Molloy's book is very good, by the way. He has you do

dpkg --add-architecture armhf
apt-get install cross-build-essential-armhf

However, the last step failed due to some missing libraries, which Molloy (the website mentioned) does not discuss, so I installed linux-libc-dev:armhf and libc6-dev:armhf, and the install of cross-build-essential-armhf worked. But it seemed to make g++ (for the i386) disappear so I installed build-essential again (a bad sign).

After the above steps, I can compile (for i386) and cross-compile (for BBB) a simple "hello world" program. However, when I try to compile something which relies on other libraries, the linker can't find them. For example, gthread-2.0, gtk-3, gdk-3, etc., a fairly long list.

Looking at /usr/lib/i386-linux-gnu, it appears that these .so files are there, but the symbolic links have been removed. For instance, libgthread-2.0.so.0 is there, but not a symbolic link to it from libgthread-2.0.so. In fact, libgthread-2.0.so does not exist, though it must have existed (I guess) when the wxWidgets example code was compiled during the wxWidgets installation process.

I could go in and manually create a dozen or more symbolic links that are missing, but I have the feeling that I'm missing some critical element in the big picture of how to cross-compile, and that this kind of manual fix would only be a band-aid on the underlying problem. I also wonder about the fact that /etc/ld.so.conf now includes directories for ARM. Should it?

[stevepusser]

I'm 99.9% sure you'll need the armhf -dev versions of all those libraries you want it to link to. It isn't much use for an armhf program to link to an i386 version of libgtk2.0.

I was able to compile a few Rasberry Pi versions of programs in a Qemu virtual machine on my amd64 machine by following this guide: https://jodal.no/2015/03/08/building-ar ... -pbuilder/

[rsfairman]

True enough -- I do need the armhf libraries for my program to link to when compiling the ARM version of the program, particularly since I am hoping to use static linking of everything the program uses. But I have yet to cross that bridge.

Right now, the issue is that the i386 libraries are messed up -- not seriously messed up, as far as I can tell, but not quite right either. Leaving ARM entirely to the side, regular i386 programs don't compile. I suspect that installing the armhf stuff somehow messed up a pre-existing fully functional (?) i386 development setup. I could figure out on a case-by-case basis which symbolic links to which libraries are missing, and create them myself, but this seems crude, and like I've overlooked something important.

I am unfamiliar with qemu and pbuilder, but if I understand, you are suggesting that I use qemu to set up a virtual machine to emulate the Beaglebone (the ARM), then build and test there. So, I might write the code on the i386 and compile and test as usual, then do exactly the same thing on the virtual ARM machine, with all the same tools, but after compiling/installing them on the virtual machine. Or I could do every bit of development in the emulator (though it would be slower), ignoring my regular development toolchain. I like this idea, though it does feel like a "gold plated hammer." But it's not clear what role pbuilder would play since the goal isn't a package as such, but a single .exe file.

[stevepusser]

I only used the method in the guide to compile already debianized source files into proper deb packages. I suppose that the same method would work if your project was also debianized.