glibc, read-only sources, and static linking
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
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.
More information about the hlfs-dev