>>>>> 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.)

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.

> I expect that the locale stuff would eventually be used by most programs
> in /bin and /sbin.

/bin/*sh programs need locale modules. But probably other programs in
/bin and /sbin don't, because others only need LC_MESSAGES.

So, providing both statically and dynamically linked shell (at least
for /bin/sh) may be an option. And this is what most UNIX-like systems
do, anyway

>   2. Fix dlopen() for static binaries

> 	There's issues such as dlopen()ing a library which depends
> 	upon parts of a dynamic libc (e.g, stdio) which have global
> 	state, and this will cause problems interacting with the static
> 	parts of the program which are using the compiled in libc with
> 	its own version of that global state.

I don't think this is fair claim. 
Because if we leave any static library as an option, the global state
problem still remains on any static libraries which have global state.

And apparently we can't/shouldn't disallow that a user creates his own
libXXX.a.

So, I think we should drop this point from Cons of 2.

>   3. Dynamically link everything against /lib

You seem to have some misunderstandings here.

> 	This appears similar to what other systems provide:
> 		- Redhat 6.2 (and other Linux systems?) has /lib
> 		  populated with the .so files that are used by /bin
> 		  and /sbin (and /usr/lib contains .so files which
> 		  are installed in /usr/pkg/lib on NetBSD.)

Redhat and other Linux distributions only have some limited libraries
in /lib. And many libraries are still linked against /usr/lib, not /lib.

If you try "ldd /usr/bin/* | grep /usr/lib", you can find many
binaries still refering /usr/lib.

> 		- Solaris 2.6 has /bin -> /usr/bin, /lib -> /usr/lib.
> 		  /sbin contains some static programs, some dynamic
> 		  programs linked against /etc/lib, and some dynamic
> 		  programs linked against /usr/lib. 

i.e. Solaris is not an example of 3.

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

> 	Similar to 3. above, except that only the .so libraries that
> 	are needed by /bin and /sbin programs are installed into /lib,
> 	and the rest of *.so remains in /usr/lib

> 	Cons:
> 		- "system" shared libraries are spread between
> 		  /lib and /usr/lib; possible user confusion

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.
--
soda