dlsym() and RTLD_NEXT resolves wrong symbol
Martin Schlemmer
azarah@nosferatu.za.org
Sun Feb 13 23:42:00 GMT 2005
On Sun, 2005-02-13 at 19:16 +0100, Jakub Jelinek wrote:
> On Sun, Feb 13, 2005 at 08:07:47PM +0200, Martin Schlemmer wrote:
> > > 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").
> > >
> >
> > So there is no way to get the latest when there is more then one symbol
> > without specifying the version (Except maybe a script that extracts that
> > info) ? (Asking because there are quite a few functions being wrapped)
>
> No and that is a good thing.
> Consider that say dlvsym would have magic 3rd argument
> DLVSYM_LATEST, meaning use the latest symbol version.
> Now, all is fine and your program works, but one day you upgrade your
> glibc to glibc-2.5.6 which added chown@@GLIBC_2.5.6 and kept
> chown@GLIBC_2.1 and chown@GLIBC_2.0 for compatibility.
> Suddenly your program breaks, as it knows how chown@GLIBC_2.1 looks like
> and what to expect from it, while it doesn't know what is chown@GLIBC_2.5.6
> about and how it behaves.
> Well, chown is probably a bad example, as it is unlikely to change e.g.
> its arguments, so think e.g. shmctl instead.
>
Understood.
> If on the other side, you with a (e.g. configure) script extract the versions
> (whether by parsing readelf -Ws output, writing your own libelf proglet or
> something else) and pass that to dlvsym, the ABI of the symbol is not going
> to change underneath of your program. If you are writing wrappers, you
> probably want to wrap all (at that time known) symbol versions of a
> particular symbol, not just one and the exact symbol versions are handy
> for that too.
>
Thanks for the help!
Regards,
--
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/4f379157/attachment.sig>
More information about the Libc-alpha
mailing list