Subject: Re: karbon problem
To: Martin Husemann <email@example.com>
From: David Laight <firstname.lastname@example.org>
Date: 10/12/2005 21:23:49
On Wed, Oct 12, 2005 at 11:08:37AM +0200, Martin Husemann wrote:
> On Wed, Oct 12, 2005 at 03:46:56PM +1300, Mark Davies wrote:
> > Looks like OpenBSD fixed their ld.so to deal with this a few weeks ago but
> > inside ld.so is not somewhere that I'll lightly tread.
> Isn't the better fix to make KLibLoader try dlsym() on the
> global handle returned by dlopen(NULL, ..) as well?
> The current behaviour does not sound like a bug to me, but maybe I
> misunderstood the situation.
> The shared library in question does *import* the missing symbol, but
> not *export* it - so dlsym() has no reason to find it in it's dlopen() handle,
If 'a.so has a NEEDED entry for b.so' and 'b.so defines symbol b'
then dlsym(dlopen("a.so", 0), "b") should load both a.so and b.so and
return the address of 'b'.
This should happen even if a.so or b.so were loaded with the main program.
Dunno if this is the problem...
David Laight: email@example.com