dlsym can't use handle returned by dlopen?

[Markus Hoenicka]

Jeremy Chadwick writes:
 > As promised: http://www.malkavian.com/~jdc/myprog.tar.gz
 > 

This test program indeed works as expected. However, this doesn't
quite reflect the situation in libdbi. I took your files and modified
them accordingly, see:

http://libdbi.sourceforge.net/downloads/dlsymtest.tar.gz

To run the test use:

LD_LIBRARY_PATH=. ./myprog

We need to set the environment variable to let the linker pick up a
shared object that gmake builds.

myprog.c now just calls a function which is provided in libmylib
(built from mylib.c). The latter file does most of what your test case
did in myprog.c. The second major change is that myshared.so is linked
against libmysqlclient (just like a libdbi database driver is linked
against the client library). myfunc now calls a MySQL function to show
that it is accessible (if you don't have libmysqlclient handy, you can
replace it with whatever function from some .so is convenient)

Finally, libmylib tries to obtain a pointer to that MySQL function by
means of a dlsym call. This new dlsym call, in contrast to the existing
one that acesses myfunc in myshared.so, indeed fails:

myint = 0xdeadbeef (3735928559)
==> entered myfunc()
==>     double = 3.141590
==>mysql client version is 50051
==> exiting myfunc()
dlsym() in shared lib failed: Undefined symbol
"mysql_get_client_version"

So, to make the problem clear again: while dlsym works when accessing
symbols in dlopen()ed objects, it fails to access symbols which are
linked into such an object if you use the handle returned by
dlopen(). This is different from other OSes.

regards,
Markus


-- 
Markus Hoenicka
markus.hoenicka at cats.de
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de