[uClibc] Toolchains thoroughly inadequate

[Keith R. John Warno]

* Mark Robson <slarty2 at ntlworld.com> [31/12/2003 0921EST]:
> Dear All, I've used uclibc for a while, and the old gcc wrappers
> always used to work well.
> 
> Ok, I've read the thread suggesting that the wrappers are no longer
> the way to go - that seems fine.
> 
> Unfortunately, I have been unable to get or obtain a working toolchain
> (i386)
[snip]

I have been using uClibc 0.9.24 for less than 24 hours but have spent
13+ hours beating it and a native i386 uClibc-targetted toolchain into
submission.  Granted I haven't built much against the uClibc yet (other
than libtool, ncurses, and bash), it seems to work (so far).  After such
a pain (and a throbbing headache this morning), and the similar anguish
of others on this list, I feel obligated to share what I did -- however
correct or not -- with others on this list.

Firstly, everything I build for my linux boxen is done so as an RPM.  So
I might be able to provide packages if folks are interested, but I make
no promise that they will work for you or even install.  I build with
RPM 4.0.4 on an pseudo LFS system (used to be SuSE 6.2 way back in the
day but now looks more like mud).  Most packages are built for
-march=i486 but some are for i386.  Better have a 686 just to be safe.
:)

Now the steps I took:

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.

2)  Build binutils 2.14 from sources, using a --build and --host of
i486-pc-linux-gnu and a --target of i386-uclibc-linux-gnu.  This puts
everything in the right place for our so-called 'cross compiler' that is
built next.

3) Build gcc 3.2.3.  Now this step I wasn't really sure of.  Again, it
is built with a --build and --host of i486-pc-linux-gnu and --target of
i386-uclibc-linux-gnu.  --with-libs and --with-headers were passed to
configure as well (but I don't know if it's necessary).  I'm only
interested in C code so only a C compiler was built
(--enable-languages=c).  The specs file had to be edited to use the
ld-uClibc.so.0 dynamic linker.

And that's it.  So far so good, but I'm sure something will misbehave
today.

There's currently no need for me to use a chrooted() environment to do
builds; the uclibc targetted compiler seems to find the right stuff it
needs on its own.  I thought 'native' system headers would get in the
way but they don't (at least not by default); the uclibc cpp is only
looking in:

GNU CPP version 3.2.3 (cpplib) (i386 Linux/ELF)
ignoring nonexistent directory "/usr/i386-uclibc-linux-gnu/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/i386-uclibc-linux-gnu/3.2.3/include
 /usr/i386-uclibc-linux-gnu/include
End of search list.

uClibc compiled libs and headers live in the lib and include dirs,
spectively, beneath /usr/i386-uclibc-linux-gnu/, and the compiler knows
to look for them there.  This is to say that uClibc-compiled libs (i.e.,
ncurses) should be installed here so the compiler can find them.  Once a
base uClibc system is up devel stuff will be rebuilt so they live in the
'real' locations (/lib, /usr/lib, /usr/include, etc).

Questions?  Comments?  All of this is strictly an experiment for me.
Résumé fodder, if you will, ultimately to be used for whatever purpose I
or my employer may concoct.

Happy New Year,
krjw.
-- 
Keith R. John Warno                         [SA, Valaran Corporation]