> I was thinking about this is the shower this morning (for some reasons
> showers is a place where I manage to think about things).

no - usually while trying not to fall into a ditch on the way home
from the pub :-)
> 
> The problem is (correct me if I'm wrong) that we get problems since
> dynamically loaded stuff might want to load yet other dynamic stuff, which
> might conflict with the static linked stuff.

An issue - but unlikely for stuff in /bin since the netbsd build
process will have rebuilt it at the same time as libc.a and libc.so.
> 
> But how is this resolved in a dynamic linked binary? The same thing can
> obviously happen there. You can have two libraries loaded, which both
> refer to a third library in turn, and they want different versions of that
> third library.

It depends on how they open the 'third' library.  If they have a 'NEEDED'
entry for it then the library symbols will be added to the programs
symbol table and (probably) first one (which may be in the program
itself) used in all cases.

However if the dlopen() the library then the library's symbol table
is kept separate, dlsym() must be used to find the value of symbols
in the library in order to call them.
> 
> So what we need for static linking to work is that dlopen needs to know
> the versions of the statically linked libraries, and make the same checks
> as usual.

No you can't do static linking [1] and dlopen(), but you can link an
archive library into a dynamically linked program.
(indeed an archive library can have dynamic libraries as its
components, and a file fred.so can be an archive library).

	David

[1] what makes an elf file static or dynamic, not whether the 
program has a NEEDED entry for libc.

-- 
David Laight: david@l8s.co.uk