uclibc vs glibc
robert at linuxfromscratch.org
Sat Nov 6 17:22:37 PST 2004
Another thing wrong with that mktools script is:
make BOOT_LDFLAGS="-static" quickstrap # bootstrap
With a make quickstrap, BOOT_LDFLAGS never gets used and the xgcc is
dynamically linked. It should be just LDFLAGS="-static". Aswell, I don't
think quickstrap does anything when languages=c, its the same as just doing
make alone. Quickstrap is usefull when g++ and friends are being built too.
On November 6, 2004 07:20 pm, Robert Connolly wrote:
> 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.
More information about the hlfs-dev