Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
User Journal

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

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?

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.
(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.

GNU is cross-platform - NOT SO MUCH

Comments Filter:
  • In the old days, I'd've just posted this to Technocrat (since I was an editor there).

    Oh well. The only constant is change.

    And I am full well aware that I am likely just screaming into a bucket here - aside from a relative handle of fans I have this will likely not be seen by anybody with the ability to do anything about it. I judge the likelihood of this being posted to the front page of /. to be of the same order as the likelihood of me winning the lottery (and I don't buy lottery tickets).

    At best, it *mig

    • Unless it gets to the front page, it won't be indexed at all. JE's get special robots.txt treatment, last time I checked. Post your rant in a newsgroup or more public blog...

  • They handle cross compiling NetBSD itself very well, but 'pkgsrc' "not so much". Makes building packages for my MIPS based Cobalt RaQ2 server "painful" :-(

    • Well, in reality that is just a reflection of the last part of my rant: many packages assume (wrongly) that BUILD=HOST=TARGET.

      It makes me think that part of what is needed would be for a package "lint" program that does a cross compile, and ideally a validation under QEMU or the like.

  • Don't really see what Red Hat could do if one can't even get glibc to cross compile. Going to take some massive work to get right..

    • Actually, the "gotchas" for getting glibc cross compiling to the ARM were:

      1) copying the GCC generated "libgcc.a" over to "libgcc_eh.a".
      2) *after* building glibc (and before building the second pass GCC) munging all the generated linker scripts to point to where the files were installed on the cross-compiling host, not where they were going to be on the target (see http://www-rocq.inria.fr/imara/wikilara/users/oliviermehani/mipsellinuxtoolchain [inria.fr] - same problem, different processor).

      Item #2 could have been so

      • by emj ( 15659 )

        I was going to say that if you get flames for patches that fixes a problem, then you are probably not solving it correctly. (Or as you say noone cares).

The shortest distance between two points is under construction. -- Noelie Alito