Re: dlsym() and RTLD_NEXT resolves wrong symbol

[Jakub Jelinek <jakub at redhat dot com>]

On Sun, Feb 13, 2005 at 01:18:48PM +0200, Martin Schlemmer wrote:
> Do I ask too much for an comment about why rather than comments about my
> understanding?
> 
> As far as I can see, the problem lies in that there are two global
> symbols:
> 
> chown@@GLIBC_2.1
> chown@GLIBC_2.0
> 
> The first being the new chown that follows symlinks, and the second being
> the old that is similar to lchown that do not follow symlinks.
> 
> So now back to my problem.  Under default circumstances on my system (with
> 2.6 kernel, etc), the newer symbol are resolved.  However, when I try to
> get the symbol via  dlsym(RTLD_NEXT, "chown"), it returns the address of
> the second (or older) symbol.
> 
> My question is thus:  Why does it not the address of the first symbol that
> would have been resolved during normal operation?  Or differently, why is
> my assumption that it would resolve the same symbol as during normal
> runtime
> wrong ?

Because dlsym is a lookup for unversioned symbol.
Program or shared library compiled/linked against glibc 2.0.x, that doesn't
contain any versioning whatsoever, is supposed to resolve to the oldest
symbol version, not to the newest.  And dlsym matches that behaviour.

The @@ symbols vs. @ symbols matter at link time, so if you are linking
against new libc.so undefined chown references become chown@GLIBC_2.1.
If you want chown@@GLIBC_2.1, just call dlvsym (h, "chown", "GLIBC_2.1").

	Jakub