glibc, read-only sources, and static linking

Bennett Todd bet at rahul.net
Wed Oct 20 06:25:35 PDT 2004


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.

The end result has a nice form for building secure servers, too; my
current pattern is to start with vmlinuz + busybox, install and
configure the servers I want, write a custom init that just starts
them alone (or for single-daemon servers just install the daemon as
init), and remove busybox. Seems to fit mjr's formula pretty nicely.

I don't like shared libs, I don't. I think they were a nice hack for
ekeing out a small additional increment of performance in the days
of small memory and disk, but these days the performance and
complexity cost they inflict seems out of proportion to the benefit.

Still have a thing or two to settle out; I'm hoping to add a
hard-wired nss_cdb into uClibc, effectively acting as though
nsswitch.conf existed and read "files cdb" for every entry except
hosts, which would act like "files cdb dns". Then I could build any
cdb maps I want from whatever source happened to be appropriate.

And this approach forces me to rebuild my perl any time I want to
add a module that includes code in C. Wish I could make a purely
static perl executable that could dynamically load extensions, but
as far as I can see that's just not an option, the extensions
themselves need to know about the symbols in libc, so allowing a
perl to dynamically load extensions means that perl won't run
without the right versions of ld.so and libc.so. Grrh.

But with some compromises, you can assemble a full, complete Linux
system with no dynamic libs or loader whatsoever.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20041020/0cd38e8d/attachment.sig>


More information about the hlfs-dev mailing list