[uClibc] Toolchains thoroughly inadequate
Keith R. John Warno
keith.warno at valaran.com
Wed Dec 31 15:45:48 UTC 2003
* 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]
More information about the uClibc
mailing list