uclibc vs glibc
robert at linuxfromscratch.org
Sun Oct 31 13:57:47 PST 2004
Hello. I know I brought this subject up before. I gave it up because uclibc is
still in developmental stages, but hlfs is in development stages too.
The main thing that bothers me about Glibc is we will never be able to rebuild
itself in the finished system with all the Grsec features enabled. With Glibc
all these programs are not PIC... gencat, getconf, getent, iconv, lddlibc4,
locale, localedef, pcprofiledump, rpcgen, sprof, iconvconfig, nscd_nischeck,
rpcinfo, zdump, and zic, and so they will not be aloud to run with disallow
textrelocs in the kernel. I tried building these progs with static linking
but that caused major failures from the tests. Another thing that bothered me
was the Glibc source not being read-only (the docs get built in the source
dir), but this is only cosmetic.
Uclibc is a good choice for us because the already support propolice and pie.
They consider text relocation a bug, while Glibc's devels couldn't care less
for these features. Google says xorg can build on Uclibc, but this might be
pretty experimental. And we wouldn't have to follow a moving target for
eternity like we will have to do with Glibc (although currently only Uclibc
snapshots will work for us).
More information about the hlfs-dev