[Talk] State of dynamic linking in various platforms...

Michael Paddon michael at paddon.org
Thu Aug 22 14:50:32 EST 2002

Luke Mewburn writes:
> 	OpenBSD
> 		Similar to NetBSD ???

Yes, except for /sbin/tbrconfig (part of ALTQ). Who knows why?

> I'm working on a solution to making NetBSD have a dynamically linked
> "world", to solve a variety of problems (such as dlopen(3) not working
> for programs in /bin and /sbin because they're statically linked), but
> there's been some reasonable objections in the past because people
> have been "burnt" on Solaris and Linux.
> My solution is to provide /rescue, which contains a "crunched" copy of
> the files from /sbin and /bin statically linked, and switch /bin and
> /sbin to dynamic linking, with certain libraries moved from /usr/lib
> to /lib and the dynamic linker moved from /usr/libexec to /lib.
> (We have to retain existing functionality of not requiring /usr for
> the first stages of the boot process).
> Recovery in the case of failure of /lib/* is to boot to single user
> mode with /rescue/sh as the shell, and prepend /rescue to the PATH.
> I'm curious to other peoples experiences with fully dynamic systems,
> and thoughts on my solution.

Statically linked executables have several key advantages IMHO:
   * faster (no run time linking necessary, but who cares with an n GHZ 
   * self contained
   * redundant (losing one .so file doesn't hose everything)

Dynamic linking, OTOH, saves disk space (who cares anymore?) and allows 
library defects to be patached far more effectively. They also use memory more
efficiently which *is* a big deal as far as I'm concerned.

One of the really nice things about statically linked executables is that you 
can whack them onto any system (which supports the correct kernel traps), 
without worrying about having to get the right libraries. This makes add on 
apps far less sensitive to the "right" version and makes binary emulation (say 
a linux executable on a FreeBSD box) more of a sure thing.

All that being said, I reckon that the memory efficiency issue trumps all for 
system executables. Make everything dynamic.

What about people who whine about recovery? Boot from floppy/CDROM of course,
fix the problem and get on with it. A worse case scenario requires this 
approach anyway, and hosing a key .so could be regarded as a catastrophic 

One interesting approach might be to have a back up ld.so and core libraries 
that the system could fall back to automatically in the case of a hard failure.

It would be really nice if third party apps provided statically linked 
versions, however, so that they can be easily run under emulation.


More information about the Talk mailing list