dlsym() and RTLD_NEXT resolves wrong symbol

[Martin Schlemmer]

On Sat, 2005-02-12 at 20:14 -0800, Ulrich Drepper wrote:
> There is nothing wrong.  You don't understand symbol versioning, that's all.
> 

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 ?


Thanks,

-- 
Martin Schlemmer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20050213/bec237d1/attachment.sig>