Re: identifying symbol versions available to dlvsym

[Nick Clifton <nickc at redhat dot com>]

Hi Manuel,

  I am sorry that it has taken so long for us to reply to your posts.

> OK, so some experimentation and additional searching showed me that
> GNU libc's fopen does not necessarily reside on /lib/libc.so.6. By
> looking into a different shared lib, one reads
>
> $ readelf -s /lib64/libc.so.6 |grep " fopen@"
>    162: 000000000005f4c0    10 FUNC    GLOBAL DEFAULT   12 fopen@@GLIBC_2.2.5
>
> which is precisely the version number that works with dlvsym().
>
> How could I have found this programatically? To identify the version
> of fopen being used, can I do better than
>
> 1) running ldd on an executable containing a call to fopen();
> 2) run readelf -s | grep fopen on each of the libs listed; and
> 3) using the first version string I find in 2) in my calls to dlvsym?

Essentially this is actually the best method.  The problem is that the version 
of fopen used will depend a lot upon the binary containing the invocation.  As 
you have seen 64-bit and 32-bit binaries will use different versions.  Plus 
there is the library load path to consider, plus any paths encoded in the 
actual binary and so on.  Running ldd resolves most of these problems to give 
you a list of the actual libraries that will be used (modulo following sym 
links of course) and then you need to use readelf or objdump to find the 
version symbol, just as you have done.

Cheers
  Nick