BSDnewsletter.com

This was proposed back in December by Luke Mewburn to NetBSD's tech-userlevel mailing list, because of the inability to call dlopen(3) from libc and other libraries. For example, this is needed for use with pluggable locales, PAM, and nsswitch using proprietary LDAP modules.

A lot of discussion covering the different ideas and issues was discussed in December and January. And now it is being discussed a lot today.

The ELF dynamic linker is moved to /lib/ld.elf_so and the shared libraries needed by dynamic /bin and /sbin programs are also in /lib.

Also, a /rescue directory is now available that contains a program made up of the these /bin and /sbin programs linked together into a single executable. (This is made by the crunchgen(1) utility.) Plus the kernel now can prompt for init's path (so you can use /rescue/init if needed).

The space savings goes from 15 MB down to around 6 MB. But that is not the primary reason.

Also, the change causes a performance drop due to symlinks (for example, /usr/libexec/ld.elf_so linked to real /lib/ld.elf_so) and running the dynamic linker.

Some proposed ideas include having build options for keeping just the /bin and /sbin static again, and improving dlopen() so it will work with static binaries.

And other ideas include improving locale and creating new daemons for nsswitch-type and user authentication work; and keeping /bin and /sbin static and placing the dynamic versions under /usr/bin and /usr/sbin -- which could be confusing.

BSD/OS also has /bin and /sbin utilities that use shared libraries. According to the BSD/OS shlib(8) manual page, both memory in running processes and disk space can be conserved, because the library binary is loaded on demand and is shared between all processes that use it. This BSDI-developed system doesn't support dlopen(3) dynamic linking routines.

Also, some Solaris systems include a /usr/sbin/static directory with a few statically-built tools available for recovery (if you can mount /usr/sbin).

Again, the changes are in the development version of NetBSD. The upcoming 1.6 release will not include these changes.

Discussion

I think you're better... - Donn
Re: I think you're better... - Arto
Dynamic linking in /bin considered harmful - W.B.Kloke
Happy w/ statically linked bins - K. Heuer
Re: Happy w/ statically linked bins - M. Weber

I think you're better...
Donn - August 26, 2002 23:57:33
I think you're better off trying to improve dlopen() so it'll work with static as well as dynamically-linked libraries. Everyone else seems to have a dynamically-linked /bin and /sbin, except FreeBSD. So why not dare to be different?

Re: I think you're better...
Arto - August 27, 2002 02:02:16
In the original discussion about this, in December 2001, Todd Vierling had this to say about dlopen() and static binaries:

"Making dlopen() "work" in static binaries is basically asking the ELF spec to bend itself over a table...."

While I don't know about the exact technical issues with this, try reading the thread at mail-index.netbsd.org. I got the impression that implementing dlopen() for static binaries would be really hard and definitely the result would not be a clean one.

Dynamic linking in /bin considered harmful
W.B.Kloke - August 27, 2002 03:23:16
Subj says it. There are a lot of people which consider dynamic linking a bad idea. There are only 2 areas where they possibly do anything good. 1st is X11. This is not the point here. 2nd is the security domain, where some things can be centrally fixed by just changing the DLLs. But it is just a lot better to rethink the whole design as the Plan9 people did. Why not make Authentication etc. available as a separate "factotum" process?

In case of /bin and /sbin the static programs in the root file systems could as well be superseded by dynamic ones in /usr/bin and /usr/sbin. Of course, you must make sure that the order in $PATH is always the one you really want. Or else. Why not dicard the whole differentiation between /usr and root, the wohle historic reasons for that being fully obsolete now?

Happy w/ statically linked bins
K. Heuer - August 27, 2002 07:53:20
I've a couple of (FreeBSD, I've to admit) systems that share a common /usr filesystem by NFS. That helps a lot when applying security fixes. Locally, the're only the statically linked binaries of the root fs. Those are enough to boot into single user mode. Moving the shared libraries from /usr/lib to /lib would require a larger root fs (as far as I can see). Thus, I'm happy with statically linked binaries in /bin and /sbin ...

Re: Happy w/ statically linked bins
M. Weber - August 27, 2002 15:24:04
Well, in NetBSD, as you can see from the figures J.C. Reed has presented, as well as what Luke Mewburn has shown in the original HEADS UP msg to the current-users mailinglist, moving to shlibs is a net gain in space, even with additional, still static-linked binaries for the recovery case. That is, 15.45 M w/ static linked stuff, 6.24 w/ dynamic & rescue, 3.83M w/ dynamic and w/o rescue stuff.

Seeing those figures, I suppose the root fs need not be larger as before :)

BSD Links