Re: Wrapping versioned glibc symbol

[Mike Frysinger <vapier at gentoo dot org>]

On Friday 24 April 2009 09:25:50 Tomash Brechko wrote:
> On Fri, Apr 24, 2009 at 14:05:43 +0400, Tomash Brechko wrote:
> > So, is there a canonical way to wrap versioned functions?  Perhaps I
> > approach the problem from the wrong side...
>
> I'm still curious learning how to solve the problem "statically"
> (i.e. at compile time), if possible at all.

symbol versions make no sense in the static case, thus there is no support for 
that

> However my colleague
> reminded me that I can just use dlsym().  First I tried
>
>   __pthread_cond_signal = dlsym(RTLD_NEXT, "pthread_cond_signal");

i think you meant dlvsym()

> This seemed to work, but in gdb I noticed that __pthread_cond_signal
> is bound to pthread_cond_signal@GLIBC_2.0, not
> pthread_cond_signal@@GLIBC_2.3.2 !

binaries need to be relinked against new libc in order for it to use the new 
symbol version ... that's the entire point of symbol versions -- ELFs already 
linked will use the version they linked against, not the latest.

> As you can see, RTLD_DEFAULT binds to my own definition, but RTLD_NEXT
> binds to @GLIBC_2.0, skipping @@GLIBC_2.3.2.  I think this contradicts
> man dlopen, that says that RTLD_NEXT "allows one to provide a wrapper
> around a function in another shared library".  The only working
> solution left is to explicitly dlopen("/lib/libpthread.so.0", ...).

dlopen() is operating correctly.  the symbol is "pthread_cond_signal", it most 
certainly is not "pthread_cond_signal@GLIBC_2.0" nor 
"pthread_cond_signal@@GLIBC_2.3.2".
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.