Hacker News new | ask | show | jobs
by warsheep 4465 days ago
You probably already know this, but setting up a cross-compiler toolchain is a super annoying task, and is very dependent on the distro you're using. I'm sure the author knows about cross-compiling, but he probably preferred clear instructions that work for any RPi user.

There might be even stronger reasons to not use cross-compilers such as weird bugs or compiler version compatibility issues.

4 comments

Indeed. Either you give distro-specific instructions (long) or you make people build a gcc cross-compiler from scratch (also long) or you gloss over that bit (prone to failure).

Many Pi users' only linux system is the Pi.

Virtualbox is free. Debian is free. Code Sourcery ARM/GCC Lite is free. I've set up ARM crosscompile environments this way in under an hour. This isn't really a superhard thing to do.

[EDIT] Vendors do this too. I went to a workshop on the Freescale i.MX line and guess how everyone got the development system? A VMware image on a thumb drive. You don't have to be a hero when it comes to cross-compiling, just get the work done.

This is anecdotal evidence from my own experience, so take it with a pinch of salt. I work on an open hardware project[1], I believe that we lose a significant portion of users (~50%) at each step deeper in to the development process. It seems that the steps are along the lines of: binaries - source releases - code from GitHub - updating firmware - compiling firmware - debugging hardware.

I think it would be useful to have a Virtualbox image available with everything set up for cross compiling for the Pi, BBB, etc. The thought of setting up non-standard toolchains seems to put off a lot of users.

I've also been working on a project[2] involving the BeagleBone Black and I saw a sharp increase in users when I began distributing an OS image with everything pre-installed.

[1] https://github.com/greatscottgadgets/ubertooth [2] https://github.com/dominicgs/USBProxy

I'm surprised it hasn't been done already. Wasn't the RPi supposed to be an "educational" product, or is this just a case of "shut up and give my my toys already"?
The whole intention of the Pi as an educational tool was to provide a clean-slate platform where users could experiment without worrying about breaking things on their OS install or having to sludge through layers of virtualisation, build systems and compiler configs before doing any programming for the target system. If what you're suggesting is that RasPi users in this original target group ought to be plumbing together virtualised cross-compilation for their Pi with their own hands, that would defeat the purpose.

Of course not everyone who wants to play with early versions of the new Q3A port falls in that category. But the fact that the Rasbpian developers themselves have steered clear of x86->RasPi cross-compilation suggests that it's not necessarily straightforward even for experienced people.

"We want to break the paradigm where without spending hundreds of pounds on a PC, families can’t use the internet. We want owning a truly personal computer to be normal for children, and we’re looking forward to what the future has in store"

That's from RPi's mission statement. It's on their website.

RPi had nothing to do with being a cheap Linux platform for hardware hackers and people who wanted a cheap XBMC or MAME box. But now it's 99% that.

I hope your OS image is GPL compliant.
It's probably a good thing to do if you're doing a lot of ARM kernel development, but for a oneshot thing? For someone unfamiliar with those tools?

It would be interesting to race someone unfamiliar with that toolchain installing it and cross-compiling versus someone just following the instructions.

If it really takes 12 hours to compile the kernel and application on the target, I think no amount of instructions would be slower.

And it's a one-shot thing, why make people compile the kernel at all?

Start the compile, eat dinner, go to bed, breakfast, go to school, eat lunch, done. Beats fighthing with a cross compiler toolchain for a one-off job by miles.

(Reminds me of a povray benchmark I did some time ago: start the render, go on a holiday trip, wait some more, done: https://groups.google.com/d/msg/de.comp.os.linux.misc/XmdkN1... )

In the 90s I built a FreeBSD firewall using discarded PC parts. It took 10.5 hours to build world and kernel. There were 2 power outages that forced me to start over each time. I bought my first personal UPS to fix that problem. I would learn how to cross compile instead of waiting 12 hours.
At the moment this is the winning result of a competition (first person to run Qiii with the open source drivers at 1080x? At 20 fps) so there are further optimisations to be made.

Once the code has been tweaked there'll probably be an image for it somewhere.

Considering this really isn't a, "have to have it right now" type feature, it's simply easier to kick off the compile and walk away.
That's great.

I haven't looked but are there documentations to allow 14 year olds who have never done this before?

So not hardware coding by any means, but I use VirtualBox to build LibreOffice on Ubuntu.
> cross-compiler from scratch (also long)

Building GCC shouldn't take more than a couple hours on a modern machine, and it's a one-time cost for a drastic speedup of every subsequent RPi build. So the aggregate time should still be considerably less than 12 hours.

I wonder why its so hard? I once built a modern gcc + glibc in my home directory on an older linux (to be able to run modern programs), and it was mostly "relocatable" or "portable" (what I mean is that you could copy it around and run it from other directories).

Couldn't somebody build a full cross-compiler toolchain as "relocatable" binaries, depending on an older kernel, and then just offer that as a binary download to run on most recent distributions? It's not a typical way to distribute a linux application, but it should work in principle.

I suggest looking at LinuxFromScratch[0], especially II.5. It's hard to do a "real" cross-platform compiler because your target system might not only be a different architecture but also has different libraries on the system with which the compiler has to work. All in all, doing it right and being able to ship binaries is a lot of work and constant maintenance as your target system, in this case Raspbian, also changes their libraries.

[0] http://www.linuxfromscratch.org/lfs/view/stable/

Some issues:

Your GCC build has to match the userspace C library (uclibc or other). If it doesn't you'll need to do all the path passing and usually link manually as well.

It has also to match the kernel somewhat (not so critical for userspace apps, but if you want to add a module or something it's critical)

So, basically what you "should do" is build the whole system together (cross-compiler + userspace + kernel), some tools do that, building first a "raw" cross-compiler, then the C library and kernel, then a full compiler with all the options applied.

Here is a great explanation of why setting up a cross compiler is so difficult.

http://www.airs.com/blog/archives/492

I use crosstool-ng to do the heavy lifting for me. [0] But lately I've been trying out musl-cross to get nice, self-contained static binaries. [1]

[0]: http://crosstool-ng.org/

[1]: https://bitbucket.org/GregorR/musl-cross

Crosstool-ng is nice, but if you have even a mildly out of the ordinary arch/libc/kernel version/etc combination it is still a massive pain in the ass. Typically I'd rather build the kernel on device overnight instead of spend manhours getting crosstool-ng to work as I want so that I can build on beefy hardware.

It tends to only be worth it if you are going to be using it more than a few times.

Wouldn't an emulator actually be faster on high-end hardware? Then you can run native tools at much faster than Pi execution speed, right?
"You probably already know this, but setting up a cross-compiler toolchain is a super annoying task"

Yes, I agree 100%, building a cross-compiler is a very complicated task.

But I think with the weight of the Raspberry Pi projects this should have been easier. This is a good project http://buildroot.uclibc.org but unfortunately it's very unstable.