by ebbix » Sat Sep 21, 2013 6:35 pm
Damn, forgot to mention that.
This will not link correctly against required libraries (other than glibc and standard libraries) as the toolchain can only link against libraries found in arm-unknown-linux-gnueabi/sysroot/lib. So you have to be careful when your software has dependencies.
Standard libraries work though:
$this->bbcode_second_pass_code('', '$ ldd /usr/bin/unrar
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6e28000)
libm.so.6 => /usr/lib/libm.so.6 (0xb6d87000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6d60000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6d40000)
libc.so.6 => /usr/lib/libc.so.6 (0xb6c12000)
/lib/ld-linux.so.3 (0xb6efc000)')
Dependencies and makedepends have to be installed on the host, no matter if they're required for building on the host or not...
And if tools that produce architecture-specific output are required (for example gcc-objc compiler, which is not included in the toolchain), then you can't use this approach. Other things as for example bc are fine though.
Until now I've been using this method to compile linux-kirkwood-dt (using prefixed toolchain), dtc and unrar (using non-prefixed toolchain) which have no dependencies to link against.
So long story short: at the moment this approach only works if you don't have libraries other than stdlibs to link against.
EDIT:
Okay, I've done some further testing. unzip was the first interesting package I found. It has only one dependency (bzip2) which it links against. With a clean toolchain (non-prefixed), it didn't build due to missing header file bzlib.h.
I then populated the toolchain's sysroot (/usr/local/arm-unknown-linux-gnueabi/sysroot) with all the files in /usr/include and /usr/lib from the current bzip2 package and tried another makepkg-run. It worked and linked against the correct libraries, the resulting binaries work perfectly on the target system. However, the makefile could still be badly written so that it won't cross-compile properly.
This is no convenient method (maybe a patched pacman could automate this? pass depends array and sysroot gets populated), but if you only need to compile some packages over and over again, then this could be an alternative. And if your package doesn't have any special dependencies, then this is definitively a nice method. My experience in compiling the kernel is: approx. 6 hours on the device, 2 hours using distcc, < 10 minutes completely cross-compiling (Core i5 2500, -j5).
EDIT²:
Turns out pacman is really the best package manager (it was a very good choice to switch from Fedora), it was very simple to tune it to my cross-compiling needs.
Setting its root and other dirs to toolchain sysroot and subdirs and using a modified config through a wrapper script, pacman can simply install all the needed dependencies (pacman-arm -Sydd dep1 dep2) without any further dependency resolving since only header files and shared objects are needed anyway. This makes the whole process relatively simple. I can provide additional information if anyone is interested.
However, even now some limitations remain. Host needs all dependencies and build-dependencies installed, too. And if any build-dependency tries to modify binaries or something, then all will almost definitively fail. And if the Makefile does crazy things, then cross-compiling might fail. I think I'll do some further research, refine this method and maybe write a complete guide for those interested.