uclibc vs glibc
sequethin at gmail.com
Sun Oct 31 15:20:50 PST 2004
On Sun, 31 Oct 2004 17:57:47 -0400, Robert Connolly
<robert at linuxfromscratch.org> wrote:
> 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).
...and uclibc is really small too, which is also good. Especially if
you want to use hlfs to develop something like an
ultra-secure-firewall-that-runs-on-a-live-cd or something like that;)
More information about the hlfs-dev