This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dlopen problems


On 16 Jul 1999, Ulrich Drepper wrote:

> I misunderstood the situation.  The function you want to call is not
> in the object itself but instead in the dependency.
> 
> The ld.so handles this correctly.  There is no bug.  This is the
> documented behaviour in the ELF specification.
> 
> Several months ago we corrected the behaviour of ld.so to follow this
> rule.  Before that your test program would have succeeded.  But this
> is really wrong.

Well, the problem exists in real life - perl is linked against db2, which
provides a dbopen(). It was possible before for perl to load a module that
was written for reading databases created with db1 and linked against
db1.85. Now the wrong dbopen will be choosen and there is really no way
around that - nothing that can be done in the perl module to prevent the
runtime linker from binding the wrong dbopen reference.

Bsically we are ignoring dependencies the modules require by linking
against the right db library.

> What we want to do at some point is to define a new flag with the
> semantics you want.  But for now there is no possbility except using
> dlopen().

I am willing to put in the work, so how should this be working?

Cristian
--
----------------------------------------------------------------------
Cristian Gafton    --     gafton@redhat.com     --       Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]