On Wed, 9 Jan 2002, John Nemeth wrote:

> On Apr 21,  2:21am, Bill Studenmund wrote:
> } On Fri, 4 Jan 2002, John Nemeth wrote:
> }
>      Couldn't this be fixed by requiring programs that want to use
> dlopen() to have an appropriate symbol table (perhaps with some
> tweaking of the tools)?  Although, I do see a potential problem that
> the symbols might be the same, but they might not refer to the same
> kind of object (i.e. an expanded structure in a newer version of a
> library that is being linked dynamically).  Another potential issue I
> see is dynamic libraries using libc functions that the main program
> doesn't.  This would require pulling in a dynamic libc.

Those are definitly problems. I think Todd's thread with Wolfgang shows
off more of the problems.

> } Oh, I don't think that's specific to ELF.
> }
> } Also, (playing the devil's advocate for a minute) are we sure that ELF
> } isn't "right"? :-) NetBSD does try to do the "right" thing. From all I've
> } seen about linking formats, ELF is rather sane. It could be that there
>
>      I'm not going to argue for or against it since I don't have enough
> information and I think it would be futile anyways.  I'm just
> questioning whether we really need to follow the aspect of the ELF spec
> that says that a static program can't call dlopen().  I.e. is there
> some way we can get around this?

From what I gather, it's not that the ELF spec says we can't call dlopen()
from a static binary. It's more that static and dynamic linking do things
which get in each others' way. :-)

I think the other thread explains it all better than I can. :-)

Take care,

Bill