uclibc vs glibc

Robert Connolly 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 mailing list