glibc, read-only sources, and static linking

Robert Connolly robert at linuxfromscratch.org
Wed Oct 20 16:06:08 PDT 2004


On October 20, 2004 09:25 am, Bennett Todd wrote:
> 2004-10-20T04:28:16 Robert Connolly:
> > 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.
>
> Why not, indeed. Bent Linux <URL:http://bent.latency.net/bent/>
> version 1.1 has no ld.so, no libc.so, no libdl, everything is
> statically linked (and stripped). I use uClibc, not glibc. The end
> result is snappy and simple, and I find it very pleasing. The
> resulting executables work on any Linux system; unlike shared libs,
> the syscall interface to the kernel seems to be beautifully stable.

I wouldn't agree to building everything statically linked. Not only would the 
size of the system get out of hand, especially with a desktop, but we would 
loose any benefits from aslr. Network daemons especially can benefit from 
aslr.

On my box /bin and /sbin together are about 18MB with about 270 programs (not 
including symlinks) mostly dynamicly linked. With glibc's libc.a those 270 
programs would use about 130MB. This is a rough guess though. And we would 
start using a lot more ram too. Surely we can balance static with dynamic 
without needing to be on either extreme.

There are many ways we could try this. Busybox (with glibc) could be used 
either in /(s)bin or in /rescue. My preference is to put libc.so in /usr/lib 
and have everything in /(s)bin statically linked, but that means disregarding 
the Filesystem Hierarchy Standard. Runtimes/loadtimes of statically linked 
programs tends to be better than with dynamic linking, which seems odd 
because of shared memory.

For now would everyone agree chapter 6's bash be linked statically? I want to 
say coreutils too, but some things are fine dynamicly linked, like sort, 
dirname, du, while others like false, mv, ls, or echo should surely be 
static. Dividing coreutils in two would not be fun to install though.

Ida know. I'm getting hungry though.

Robert



More information about the hlfs-dev mailing list