[Talk] State of dynamic linking in various platforms...
lukem at wasabisystems.com
Thu Aug 22 15:11:36 EST 2002
On Thu, Aug 22, 2002 at 02:58:09PM +1000, Peter Jeremy wrote:
| >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),
| I think a more correct solution is add hooks so that it is possible
| to call dlopen(3) from a static binary, rather than move to dynamic
| linking. I think this topic has been thrashed out recently on one
| of the FreeBSD lists and people aren't keen to move to a fully
| dynamically linked FreeBSD.
Suggested "solutions" for allowing static ELF binaries to use dlopen(3)
came up on the NetBSD mailing lists as well:
- It breaks the ELF spec (so I'm told by the ELF gurus).
- It's not trivial to implement.
- There's many corner cases with libc global variable shadowing
(e.g, __sF in stdio).
These strike me as a hacks suggested by people who are dead set against
dynamic linking /bin and /sbin (usually for reasons such as "I got
screwed on Solaris once by this" (*)), so they come up with more &
more radical ideas (not working code, mind you) as solutions to each
of the objections, each idea more complicated than the last. All to
avoid having a dynamic linked /bin. (``KISS'', anyone?)
Ironically, they're generally happy with the current "half cocked"
solution that has /bin and /sbin statically linked and /usr/*
dynamically linked... If they're that worried, why not fall back to
a fully statically linked system? (I bet 99% don't)
(*) For a long time I felt this way myself, because of lossage on a
Solaris box. Implementing decent in-tree recovery tools removed my
| Note that dynamic linking is not a cure-all for everything. There are
| security and performance reasons for retaining the ability to link
| applications statically.
Sure, programs will still be able to be statically linked.
But they won't be able to take advantage of dynamically loaded
functionality such as:
- third-party nsswitch modules
- foreign locales
(and a bunch of other stuff that I'm sure could use dlopen(3)).
There are security advantages to dynamic linking as well, such as only
needing to upgrade /lib/libc.so.12 when there's a libc buffer overflow...
I can see arguments on both side of the "security" fence for this change.
More information about the Talk