[uClibc] Toolchains thoroughly inadequate

[Erik Andersen]

On Wed Dec 31, 2003 at 04:38:59PM -0500, Keith R. John Warno wrote:
> * Keith R. John Warno <keith.warno at valaran.com> [31/12/2003 1045EST]:
> > 1) Build uClibc 0.9.24 from sources.  This was surprisingly painless
> > given the similarity to kernel configuration. :)  The entire blob
> > (runtime and development stuff) is installed beneath
> > /usr/i386-uclibc-linux-gnu/, granted i386-uclibc-linux-gnu may not be a
> > valid target spec but I don't particulary care.  Attached is my config.
> 
> Oops.  I was politely reminded off list that my config was *not*
> attached.  It should be now.  :>
> 
> During the course of continuing experimentation today I've run into a
> few more headaches, all of them related to configure scripts (which I
> should have expected after googling, rtfm'ing, yada yada).

<ladies and gentleman, we have a winner!>

And there you have it....  The reason why cross building is
painful -- configure scripts go poking about your build system
and find the build system's headers, libraries, etc.  This is one
of the additional reasons the gcc wrapper was scuttled.  I guess
I didn't mention it, but this is certainly a reason why Manuel
and I have much less hair than we used to have.  :-)

Working with a subbordinate, foreign toolchain (i.e. a uClibc
toolchain living on a glibc host system) means every configure
script needs to be carefully checked, and in most cases, fixed
to ensure they work properly, have no tests trying to run target 
code on the build system, etc. 

We then encourage people to build their own systems a standalone
development system, since it avoids exactly the headaches you are
having.

> For example,
> configure is bound to look around for libs or headers and find stuff
> that is glibc-based (in /usr/{lib,include}, /usr/local/{lib,include},
> etc) rather than the uClibc-based stuff, thus causing all sorts of
> havoc.  Two ways around this:
> 	1) Use a chroot(). :)  As recommened on the uclibc site.
> 	2) Hack/patch offending sources.
> Both ways are time consuming and problematic.  And even if you use a
> chroot() some source hacking is close to inevitable.

For buildroot we use #2 -- but only for the purpose of compiling
up a standalone development system.  And then we expect folks to
use that standalone development system to supply them with #1.

And honestly, the only time you need to patch anything when
building within a uClibc only chroot/standalone development
system, is when the code is broken or does something that is not
supported by uClibc.  I've used the uClibc dev system to compile
up a significant chunk of Debian.  So I can at least attest to
the fact that it works for me.

Feel free of course to dance to the beat of a different drummer,
just be aware that folks have tried most of the other drummers
and after a while, have found them lacking.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--