Recently, I have made fairly major changes to kernel-package, and there were some reports that I had managed to mess up cross compilation. And, not having a cross-compilation tool chain handy, I had to depend on the kindness of strangers to address that issue. And, given that I am much less personable than Ms Vivien Leigh, this is not something I particularly look forward to repeating.
At the onset, building a cross compiling tool chain seems a daunting task. This is not an activity one does frequently, and so one may be pardoned for being non-plussed by this. However, I have done this before, the most recent effort being creating one to compile rockbox binaries, so I had some idea where to start. Of course, since it is usually years between attempts to create cross-compiling tool chains, I generally forget how it is all done, and have to go hunting for details. Thank god for google.
Well, I am not the only one in the same pickle, apparently, for there are gobs of articles and HOWTOs out there, including some pretty comprehensive (and intimidating) general tool sets to designed to create cross compilers in the most generic fashion possible. Using them was not really an option, since I would forget how to drive them in a few months, and have a miniature version of the current problem again. Also, you know, I don’t feel comfortable using scripts that are too complex for me to understand – I mean, without understanding, how can there be trust?
Also, this time around, I could not decide whether to cross
compile for arm-elf, as I did the last time, or for
the newfangled armel target. A need for quickly
changing the target for the cross compiler build mechanism would be
nice. Manually building the tool chain makes a wrong decision here
expensive, and I hate that. I am also getting
fed up with having to root around on the internet every time I
wanted to build a cross compiler. I came across a script by Uwe
Hermann, which started me down the path of creating a script,
with a help option, to store the instructions, without trying to be
too general and thus getting overly complex. However, Uwe’s
script hard coded too many things like version numbers and upstream
source locations, and I know I would rapidly find updating the
script irritating. Using Debian source packages would fix both of
these issues.
I also wanted to use Debian sources as far as I could, to ensure that my cross compiler was as compatible as I could make it, though I did want to use newlib (I don’t know why, except that I can, and the docs sound cool). And of course the script should have a help option and do proper command line parsing, so that editing the script would be unnecessary.
Anyway, all this effort culminated in the following script: build cross toolchain, surprisingly compact. So I am now all set to try and cross compile a kernel the next time a kernel-package bug comes around. I thought that I would share this with the lazy web, while I was at it.
Enjoy.
The next thing, of course, is to get my script to create a qemu base image every week so I can move from user mode Linux to the much more nifty kvm, which is what all the cool kids use. And then I can even create an arm virtual machine to test my kernels with, something that user mode linux can’t easily do.
Comments
If all you need is a binary toolchain based on Debian sources for ARM (Lenny) or armel (lenny, squeeze or sid), these are available via Emdebian. http://www.emdebian.org/tools/crosstools.html Install emdebian-archive-keyring to make Secure Apt work properly, add the apt source. e.g. for unstable:
and use
Alternatively, install emdebian-tools and let emsetup -v -a armel do the work for you. gcc-4.4 is pending.
Emdebian has scripting to create all the binary toolchains on a semi-automated basis. http://www.emdebian.org/svn/browser/current/emdebian/trunk/buildcross/trunk
BTW - the text area to make a comment appears very narrow in epiphany - is there a way to make it wider?
Yes — I believe I had come across mention of Emdebian while researching this time. But the problem I was trying to solve was more general — and not just arm/armel/embedded architectures. The use case solved by my little script is about how to create cross compilation from any native architecture to any other architecture — so I can build a SPARC cross compiler on my machine, with this script.
There is also the issue that if I use the Emdebian stuff, I would never learn what is going on under the hood. Now I know.
“But the problem I was trying to solve was more general — and not just arm/armel/embedded architectures”
I only gave those two as examples. Emdebian has pre-built binary toolchains for most Debian architectures (including m68k, ia64, mips, mipsel, sparc, hppa, powerpc and alpha) and going back as far as gcc-3.3 http://www.emdebian.org/debian/pool/main/g/
“There is also the issue that if I use the Emdebian stuff, I would never learn what is going on under the hood. Now I know.”
True, but you’ve also got the assurance that the Emdebian toolchains are in widespread usage, reproducible and quite well tested.
I can really recommend http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool for any use case.
At work we previously used Buildroot for this, but since crosstool came back to life we’ve successfully deployed several versions and archs of toolchains (little and big endian arm).
Regards //Joachim
This is now http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526884
I have now implemented a version of that patch here.
Actually, crosstool is what I was thinking about when I said: pretty comprehensive (and intimidating) general tool sets to designed to create cross compilers in the most generic fashion possible Yes, I have seen crosstool. Like the Emdebian stuff, it is big and scary. Even with command line parsing and help functions, my script is 158 lines of code, and generates a cross compiling tool chain from sources downloaded from Debian, and nothing hard coded. I takes just 5 options, none really mandatory.
There is something to be said for a miniature script that is easy to understand, and which deploys a cross compiling tool chain, and is trivially simple to learn and understand, no? I downloaded crosstool. I spent about an hour on it — and I still had not internalized all that it did.
The same holds for the Emdebian stuff — I do not understand what is going on under the hood, and I can’t change it easily. How do I, for example, say that the sources should be brought in from Debian? Or, alternately, from the FSF? (I can write a watch file for either, and run uscan to get the sources). I asked for newlib to be compiled too — and compiled gcc with newlib. Can I easily add or remove such features from the resulting tool chain? With a trivial script, it is easy. With great big complex generic helper frameworks, I get lost.
So writing this script did not arise out of ignorance — I am, and was, aware of the plethora of tolls out there to do so. They just were not nimble enough to fit my needs — and this script occupies a different niche from the grand tools and proceses.
You may be interested to know that the Debian source packages actually contain support for this. Read debian/README.cross in both the binutils and gcc source packages for details.
Basically, it boils down to using dpkg-cross to turn a libc package into a libc-cross package, create a file in debian/ with the architecture you want to build for, regenerate debian/control, and build the package as normal. Pretty simple, really; I’ve done this a lot of times