[Talk] State of dynamic linking in various platforms...
michael at paddon.org
Thu Aug 22 14:50:32 EST 2002
Luke Mewburn writes:
> 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