uclibc vs glibc
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.
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/22.214.171.124.2/100-uclibc-conf.patch ?
> 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 ?
More information about the hlfs-dev