Luke Mewburn wrote:

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

As Noriyuki Soda <soda@sra.co.jp> points out the problem isn't limited
to libc. Any library with global state that is linked into an
application both statically and dynamically can lose ... libc is the
most obvious and common though I'm sure.

HP-UX is an operating system that allows dynamic loading of libraries
by applications that have statically linked libraries.  It is not
supported to load a library that has been statically linked, but
applications can do it and it doesn't always fail.  (I'd prefer if it
did fail, loudly and obviously, every time!)

The usual way a developer achieves duplicate linking is by statically
linking libc and then dynamically loading some library that has a
dependency on libc.  Unless the developer knows to check the
dependencies of the libraries being loaded with dlopen() the problem
is not obvious since ldd on the executable doesn't show any problem.

Developers don't like it when they're told that what they are doing is
not supported and can't work reliably.  Unless you can make dlopen()
fail when loading a library that is already statically linked I would
therefore recommend against choice #2:

    2. Fix dlopen() for static binaries

Regards,

Giles