identifying symbol versions available to dlvsym
Fri Dec 21 16:23:00 GMT 2007
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.
More information about the Binutils