uclibc vs glibc

Ken Moffat ken at kenmoffat.uklinux.net
Sat Nov 6 13:39:19 PST 2004

On Sat, 6 Nov 2004, Robert Connolly wrote:

> Okay. Now I sorta have gcc/g++ pass 2 built with the cross compiler and
> --build/host/target=i386-linux-uclibc. It should be a native uclibc compiler
> I assume, make bootstrap works with it too. But after installing a native
> binutils configure scripts still say the host system is i686-pc-linux-gnu,

Did you patch binutils, e.g. using
buildroot/toolchain/binutils/ ?

I haven't built uclibc recently, but my understanding is that things
still need to be patched.  Or maybe the LFS build method has to be
altered (wish I'd had time to grok Ryan's crossbuild scripts)...

 The attached script was posted by Rob Landley on the uClibc list back
in May.  It's the first part of LFS-5.0 using uClibc.  At the time he
posted it he'd got it to compile "hello world".  I believe after that he
went on to build busybox.  You'll see that building and installing the
programs are done at different times.  I meant to give this a try on
i586, but it got put to one side.  The comments at the start suggest
that it's a bit like cross-compiling, you have to use the new toolchain
to build uclibc, but you can't install it until uclibc is available.
Then again, maybe he was taking a shortcut to avoid rebuilding binutils
and gcc.

> and a more serious problem is /usr/include is still being checked for
> headers. Anyone know what determines the default include directory? is it gcc
> (that wouldn't make sence here)? gawk and coreutils for example are going
> beyond $(prefix)/include and searching /usr/include.

From memory, /usr/include _is_ the standard.  Maybe try -nostdinc with
-I for where you want it to look ?


 das eine Mal als Tragödie, das andere Mal als Farce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mktools-uclibc-phase1.sh
Type: application/x-sh
Size: 5357 bytes
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20041106/4b503f7a/attachment.sh>

More information about the hlfs-dev mailing list