glibc, read-only sources, and static linking

Robert Connolly robert at linuxfromscratch.org
Tue Oct 19 21:28:16 PDT 2004


I just noticed "--enable-bind-now" for glibc's configure. Looks like a good 
idea to use. It works fine in chapter 5 and 6. Put "enable-bind-now" in 
google to learn more, in particular:
http://elfsh.segfault.net/papers/elf-rtld.txt

I would really like to use a read-only source tree but it seems Drepper has no 
intention of allowing Glibc to use read-only sources, as per:
http://sources.redhat.com/ml/libc-alpha/1999-q1/msg00226.html
http://sources.redhat.com/ml/libc-alpha/2003-06/msg00042.html

I tried making a patch for manual/Makefile and manual/libc-texinfo.sh to use 
$(objpfx) but it didn't work out, maybe next time. One way that did work 
(just to make sure manual/ was the only issue) was taring manual/, deleting 
everything in manual/, make glibc-source read-only, mount a ramfs to 
glibc-source/manual/, and unpack the tarball back into it. Aside from that 
everything else worked out. lndir(1) from xorg works on packages that don't 
have configure scripts (like bzip2 and others). Just take lndir.c and `gcc -o 
lndir lndir.c` (-static might be a good idea too) and it works without any 
dependencies.

I think a read-only source tree is usefull in that everything can be unpacked 
on a cdrom, and patches not normally used in chapter 5 would be... (like the 
coreutils patches, texinfo and bash stability patches, etc) which would 
increase 'regularity'. In general I think its a better model, if only Glibc 
would cooperate.

Also, I wonder if anyone wants to discuss statically linking programs, such as 
bash. In the event /lib/libc-2.3.3.so (or whatever) were damaged or missing 
we would be completely inoperable with the current setup. Some people have 
a /rescue directory with a handfull of statically linked programs, but I'm 
not sure how practical that is. Part of me says bash should be statically 
linked at a minimum, and another part says why stop there.

Robert



More information about the hlfs-dev mailing list