On Sat, Dec 22, 2001 at 04:47:06AM +0900, Noriyuki Soda wrote:
  | >>>>> On Fri, 21 Dec 2001 12:19:58 +1100,
  | 	Luke Mewburn <lukem@wasabisystems.com> said:
  | 
  | > A long-standing problem in NetBSD is the inability to call dlopen()
  | > from statically linked binaries (or even attempt to link in dlopen()
  | > with -static in some cases). 
  | 
  | Your proposal is somewhat ambiguous for me.
  | Do you intend to make static binaries unsupported?
  | Or do you intend to leave static binaries as an option?
  | 
  | I support you to make /bin and /sbin dynamic, but I really want to
  | leave statically linked system as an option.
  | (Note that there are NetBSD ports that don't have dynamic libraries,
  |  yet.)

Creation of static binaries will still be supported.

The ability to build the entire system static will still be supported.

The ability to build the system `as is' (/bin, /sbin, and some other
bits static, rest dynamic), will still be supported and for at least
the short term, be the default.


  | I don't have problem with that statically linked binaries don't have
  | full features. (Actually, this is already true. Statically linked
  | binaries cannot use multibyte locales.)
  | But I want that statically linked binaries are usable.
  | For example, I will not have problem, even if statically linked
  | binaries cannot use LDAP as name service. But If statically linked
  | binaries cannot use /etc/hosts or DNS as name service, it cause
  | trouble to me.

For the specific case of nsswitch, the existing compiled-in databases
will still be available, albiet with user control over whether the
compiled-in implementation of "nis" takes priority over the shared
nss_nis.so, or the other way around.  (This is related to but not
specifically affected by my proposal).


  | >   3. Dynamically link everything against /lib
  |
  | 3 requires that root filesystem is large enough.
  | But as far as we still support that root and /usr filesystems are
  | separated, I think we should pay attention to keep root filesystem
  | small enough.
  | 
  | In other words, I prefer the following 4.
  | 
  | For me, 3 is too aggressive at least for now.
  | Note that even linux pays attention to keep root filesystem small.
  | 
  | >   4. Dynamically link /bin and /sbin against /lib, rest against /usr/lib
  | 
  | As I said above. Linux is a system that "system" shared libraries are
  | spread between /lib and /usr/lib. Have you heard any complaint from
  | Linux users about this? At least I haven't.

After considering feedback from various sources on the merits of
option 3 versus option 4, I'm leaning more towards option 4 myself.


I performed a size comparison of some of the options recently:

	directory	existing	option 3	option 4
	---------	--------	--------	--------
	/bin		5743		814		814
	/sbin		10923		1909		1909
	/lib		0		15312		3955
	---------	--------	--------	--------
	total  /	16667		18035		6678

	/usr/bin	14424		13524		13524
	/usr/sbin	7238		7133		7133
	/usr/lib	170746		155434		166791
	/usr/libexec	10882		10356		10356
	---------	--------	--------	--------
	total  /usr	203290		186447		197804

	/ + /usr	219957		204482		204482

In the option 3 & 4 cases, various /usr directories get slightly
smaller because various tools which are statically linked in those
directories (`recovery' tools like tar, etc) are now dynamically linked.

Thus, option 4 saves ~ 10 MB in the root file system /, and a small
amount of space in /usr.

Adding between 1 and 4 MB for a /recovery directory, and we still
save at least 6 to 9 MB in /.  (See a previous post of mine
describing one /recovery solution which takes 1.6 MB).
In any case, /recovery could grow to 10 MB and we'd still be at
the same position that we're at now!

Luke.

-- 
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - NetBSD hackers for hire
NetBSD - the world's most portable UNIX-like operating system