uclibc vs glibc

Robert Connolly robert at linuxfromscratch.org
Sat Nov 6 16:20:45 PST 2004

That mktools script doesn't work for me as-is. It uses --enable-shared in gcc 
which builds libgcc_s.so which depends on libc.so.6 being in /tools/lib. It 
will link to uclibc but the gcc compiler is depending on glibc installed 
too /tools too, which is in comments, which may be why the author didn't 
notice it was a problem, or maybe I messed something up. But anyway it showed 
me something about /usr/include. LFS's specs patch removes /usr/include from 
the search path, uclibc's specs patch does not.

If I use --disable-shared it works well. Gawk builds with it and links to 
uclibc's libc.so and ld.so. But now I have a brain teaser in how to build the 
native compiler. Using this mktools method builds uclibc with a linux-gnu 
compiler which is supposedly not good, it should be built with a cross 
compiler (according to uclibc.org).

So I'll retry using a combination of the mktools method with uclibc's patches 
and --target=uclibc, install it to /tools/stage1 or /tools/cross linking 
to /tools/lib. Letting binutils and gcc install the cross tools 
to /tools/i386-pc-linux-uclibc might not be a good idea because they are 
cross tools that will be overwritten by native tools, hence /tools/cross.

Or something.

On November 6, 2004 04:39 pm, Ken Moffat wrote:
> 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 ?
> HTH,
> Ken

More information about the hlfs-dev mailing list