Giles Lean <giles@nemeton.com.au> wrote:
>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.

This also isn't limited to just (mostly-)static programs - as long as a
single library is linked statically into the program, and also loaded
dynamically (most often as a dependency of another library which is
dlopen()ed), there is potential for this lossage.

Still, the facts remain:

1. There are times when it is useful (e.g. faster loading) and even
necessary (e.g. recovery) to have static binaries.

2. There are times when it is useful for a program, whether statically
or dynamically linked itself, to (optionally) load pieces of code, etc.
from shared objects.  This is the functionality currently provided to
dynamically linked programs by dlopen(), but missing in statically
linked programs.

We may pass around possibilities as to how to handle this issue with
our own /bin and /sbin programs, but the fact remains that anything
short of solution #2 is simply a workaround.  Yes, solving the issues of
getting solution #2 right might take much work, and may involve changes
to the dynamic loader (getting it to e.g. recognize pieces of global
state in a library being dlopen()ed which are already present in the
running static code and apply the necessary fixups to the dynamic code
being loaded to make it use those already-present pieces instead of
creating its own new global state), the linker (making sure it leaves
enough information in the linked binary and libraries for the dlopen()
code to do the necessary fixups), and maybe even the kernel.  But it
remains the only solution (of those offered in this thread) which is
a full solution, and not a workaround.  And isn't full and proper
solutions one of the things which the NetBSD project has been
committed to from the start?

jdarrow

-- 
John Darrow - Senior Technical Specialist               Office: 630/752-5201
Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
Pager via email: 6303160707@alphapage.airtouch.com      Pager:  630/316-0707
Email: John.P.Darrow@wheaton.edu (plain text please, no HTML or proprietary)