Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GNU is cross-platform - NOT SO MUCH

wowbagger (69688) writes | more than 5 years ago

User Journal 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.

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/', 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.

Sorry! There are no comments related to the filter you selected.

Pity Technocrat is no more (1)

wowbagger (69688) | more than 5 years ago | (#26960037)

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 *might* be indexed by Google, and eventually show up in the (fruitless) searches of other folks in the same boat I am in. If you are one of those folks - sorry, I don't have any good suggestions.

Re:Pity Technocrat is no more (1)

Short Circuit (52384) | more than 5 years ago | (#26961411)

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

NetBSD is in a similar boat... (1)

rthille (8526) | more than 5 years ago | (#26964017)

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

Re:NetBSD is in a similar boat... (1)

wowbagger (69688) | more than 5 years ago | (#26969769)

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.

Bad tools for crossc (1)

emj (15659) | more than 5 years ago | (#27054111)

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

Re:Bad tools for crossc (1)

wowbagger (69688) | more than 5 years ago | (#27055499)

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 [] - same problem, different processor).

Item #2 could have been solved if glibc would just support sysroot in all the damn subdirectories.

Then there were all the "gotchas" on the second pass of gcc:
1) copying all the glibc generated files from ${sysroot}/usr/include to ${sysroot}/sys-include, as the stupid GCC second pass won't add ${sysroot}/usr/include to the system headers.
2) Copying some needed glibc generated files from ${sysroot}/usr/lib over to ${sysroot}/lib, as (again) the GCC build won't look in ${sysroot}/usr/lib. (namely, crt*.o, libc.*, *pthrea* , and libm.*)

The sad thing is that these problems have been around since 2000, yet the GCC folks haven't resolved the second 2 items, and the glibc folks haven't resolved the first two. And if you start trying to point that out on the lists, you'd best wear your Nomex(TM) undies.

Re:Bad tools for crossc (1)

emj (15659) | more than 5 years ago | (#27057689)

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

Kudos & good luck (0)

Anonymous Coward | more than 5 years ago | (#27061881)

At least you've brought this to more people's attention.

I'm a real ARM fan - used to code for it in assembly on the Archimedes - and had a (downloaded) cross-compile chain set up at one stage for my Sharp Zaurus.

Real shame to hear compiling it is this much trouble, as netbooks could be a second wind for ARM rather than just being stuck in cell phones.
The Beagle board looks very cool too.


Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?