This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: dlsym() and RTLD_NEXT resolves wrong symbol
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