Robert Connolly robert at linuxfromscratch.org
Mon Jan 10 23:29:48 PST 2005

On January 11, 2005 01:38 am, Archaic wrote:
> On Mon, Jan 10, 2005 at 10:43:50PM -0500, Robert Connolly wrote:
> > I know this might sound harsh, but I'm just saying it should be possible
> > to get away with zero static libs on a development box.
> >
> > Comments?
> My only comment would be what do we actually gain from this in terms of
> security or stability?

It is possible for a dynamically linked program to put a static library inside 
itself. tclsh will do this if you use --disable-shared. I don't think that 
works with shared objects though because they're linked and loaded 
differently. OpenSSL is a library that will have regular upgrades for 
security vulnerabilities, and others too. If there are no static libs then 
you can be sure upgrades will affect all the programs. This is more 

LFS installs both so we have a more robust development environment, but for 
et_dyn static is discouraged. Removing the static libs entirely is a mild 
enforcement of an et_dyn object policy.

Aside from upgrading, I think this would be most helpful on boxes with users 
who compile their own programs; with the hardened gcc specs and no static 
libs everything they compile should be relocatable (pic) unless they 
deliberately set -no-pie. Or for admins who don't pay close attention to how 
their new packages are being linked.

I can't really think of things that are bad with this plan. Most of the static 
libs will never get used, and of the ones that do get used its only a couple 
times. I've been checking why insmod.static needs to be static, and loading 
elf support is the only reason I can come up with, but since elf is native 
for any modern system this isn't an issue; elf support should be built in.


More information about the hlfs-dev mailing list