glibc, read-only sources, and static linking

Bennett Todd bet at rahul.net
Thu Oct 21 08:02:31 PDT 2004


2004-10-20T23:06:08 Robert Connolly:
> I wouldn't agree to building everything statically linked.

I quite understand; as far as I know, I'm a minority of 1 in this
respect:-).

> 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.

aslr I don't know about, but the size question deserves closer
examination.

> On my box /bin and /sbin together are about 18MB with about 270
> programs (not including symlinks) mostly dynamicly linked.

On mine, /bin is 2.6MB, /sbin is 2.6MB, and busybox is counted in
each since it has hardlinks in both dirs. All up that's 39 programs,
plus 181 additional links to busybox. That's all statically linked.

> With glibc's libc.a those 270 programs would use about 130MB.

With glibc, dynamic linking is a heck of a lot more important, since
it's so viciously bloated; "small" has never been a goal. uClibc on
the other hand doesn't bloat executables up nearly so badly.

> And we would start using a lot more ram too.

If you're using glibc, I agree; with uClibc it's not nearly so
clear. Sure, there might be some small savings left, but on a normal
system they're no longer nearly so important.

> Surely we can balance static with dynamic without needing to be on
> either extreme.

And for a general-purpose, glibc-based system that would surely be
the way to go.

> Runtimes/loadtimes of statically linked programs tends to be
> better than with dynamic linking, which seems odd because of
> shared memory.

Not at all, firing up statically linked programs involves a little
bit of page mapping and some bulk copying; dynamic linking involves
fixups.

> For now would everyone agree chapter 6's bash be linked statically?

I retire from the discussion at this point, since I don't have
relevent experience to help you with the tradeoffs in your
distro. Just wanted to point out a radical extreme for
consideration, sometimes that can be helpful.

-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/20041021/2fde3021/attachment.sig>


More information about the hlfs-dev mailing list