GNU is cross-platform - NOT SO MUCH

Journal wowbagger's Journal: GNU is cross-platform - NOT SO MUCH 8

Journal by wowbagger on Monday February 23, 2009 @02:38PM

I used to say that the wonderful thing about the GNU software stack was that idea that you could design a brand-new microprocessor, implement a GCC and binutils backend for it, make a few changes to the Linux kernel, pull down the sources, do a "for * in packages; do TARGET=mytarget make all install; done" and have a working set of software for that new processor.

That may be the ideal. The reality - not so much.

Consider what ought to be a very simple case: Build binutils, GCC (C and C++), and glibc for the OMAP3 processor, so that you can cross-compile applications on your nice quad-core i7 CPU box and run them on your Beagleboard.

Ought to be a snap, right? Especially if you are running Debian Lenny on both your workstation and the Beagleboard, right? It ought to be just an "apt-get" away to get the crosscompile packages, no building required, right?

<sarcasm>
Come over to my house - after we do the install I'll show you the ocean view from the high-rises in downtown Wichita. The mountains are really breathtaking.
</sarcasm>
(For the US geographically impaired, look here.)

First of all, you cannot install the GCC cross-compiler for ARM, as the packages are busted right now. (In fairness, these packages are not in the main Debian repositories, but they are in the Embedded Debian repo).

OK, so, let's cross compile.

Building binutils and the first pass on GCC (C compiler only) is pretty straightforward.

Now, go look at all the articles/web pages/books on cross compiling, and you will see them usually pointing you toward ulibC, or other C libraries other than GLIBC. "Yes, so what? They are targeting small embedded systems and GLIBC is so large, plus there are the issues of licensing."

No, that's not the reason. The reason is that building GLIBC in a cross-compilation environment is well-nigh impossible.

First, there is the inconsistency on the cross-compilation setup itself. For binutils/GCC or just about any other package, you specify TARGET="your-target-arch" to say "Yes, I may be BUILDING on an x86, but I'm going to be RUNNING on an armel-linux-gnu". Not GLIBC - there you either specify HOST="your-target-arch", or better still you specify what compiler, linker, library archiver, such you want to use and GLIBC "figures it out itself" (because specifying several different but related pieces of information isn't error-prone or anything like that). Indeed, setting the TARGET= for glibc won't do ANYTHING (not even throw a warning that it won't work). Nice, guys. Way to be consistent.

Then there is the fact that as of glibc-2.7, even when you get that right it WON'T BUILD. You get the following errors:
make[2]: *** No rule to make target `/USER/src/arm-linux-gnueabi/build/glibc/dlfcn/libdl.so.2', needed by `/USER/src/arm-linux-gnueabi/build/glibc/elf/sprof'. Stop.

Go ahead, search the web for that error (you'll want to strip out the "/USER/src/arm-linux-gnueabi/build" part as that is specific to where I am building it).

This problem has been around since 2000. This is not a problem that I alone am seeing. Do you see any solutions to the problem listed in that search? I don't.

This is a pretty severe issue. If you cannot build glibc, you cannot build the C++ compiler. You cannot link programs. You are dead in the water.

And don't bother asking on the crossgcc list. I've done so, and I got one basic response - "you can't do that".

Now, there is a tool called "crosstool" that purports to handle all the patching, hacking (in the pejorative sense) and general screwing around to allow you to build glibc. Pity it doesn't have support for the latest compiler and glibc.

Doesn't it say something when you have to have a tool that patches and generally fiddles about to make the glibc compile? Something like "THIS NEEDS TO BE CLEANED UP!"?

"Oh, but GLIBC is *special* - it has to know about the kernel, and the C compiler, and lots of other things. It's going to be tricky to build." Tricky, yes - if there were GOOD, step by step instructions on how to build any given revision of GLIBC I could forgive that.

Search the Web - I've not found any.

OK, skip it. Like some of my college professors would say, "Assume the existence of the compiled library." So, let's cross compile some programs.

Nope. While many programs can be compiled on a wide range of architectures, they cannot be cross-compiled at all. They MUST be compiled on the same architecture as they are being built for.

Look at the Openembedded project. They way they purport to work around this is to have "recipes" that tell them how to build given programs - some get cross-compiles, many get compiled under qemu emulating the target processor.

(Not that I've been able to get Openembedded working, either. All my questions have been met with "Oh, the released version of the tool is busted - get the good version from Subversion" Of course, the Subversion version doesn't work either. And we won't talk about the fallacy "Fixed in $REVISION_CONTROL_SYSTEM := fixed" - that's a separate rant.)

Does it seem crazy to YOU to spend the time coming up with kludgey work-a-rounds for broken Makefiles? Why not simply identify the areas in the Makefiles that are making the broken assumption that the CPU that will run the code is substantially the same as the CPU building the code?

"oohhh, but that's *hard* - and some upstream package maintainers won't accept our patches because they don't feel it's important."

In my opinion, what needs to happen is that *somebody* - Redhat, Debian, Canonical, IBM, Google: I don't CARE who! - needs to make cross-compiling a priority. Imagine what would happen if Canonical said "OK, as of Limpid Llama no packages will be accepted for Ubuntu that don't cross-compile successfully for x86, ARM, PPC, MIPS, and x86-64. Just compiling ON those platforms is not enough - you HAVE to be able to cross-compile FOR those platforms from a different platform as well."

Consider the emerging non-x86 netbook market (which also will include things like the Dell asymmetric processor laptops with an OMAP and an x86) - do you REALLY want to have to build all of Debian on an OMAP just to get that platform supported? Shouldn't it be possible to do the builds on a nice many-core i7 box instead?

I think many of us who follow Free Software have fooled ourselves about the state of support for different architectures for far too long. I think that needs to change.

This discussion has been archived. No new comments can be posted.