Re: dlsym() and C++

[Magnus Norddahl <mbn@dark.x.dtu.dk>]

Quoting Jeff Read (bitwize@geocities.com):

> I've had no problems running dlopen() and dlsym() on a C++ library.
> Xhedgehog and GNUdius both rely upon C++ objects and functions
> encapsulated within DLL's. But the symbols I'm trying to access have all
> been declared extern "C".

Yes, I did notice that if I declared the C++ functions extern "C" in the
coredumper test library, it works. According to Bjarne Stroustrup's book,
the only thing extern "C" means is that it uses C naming convention instead
of C++'s. Maybe the dynamic loader has a problem with C++ symbol names, I
don't know...

My brother did use quite some time trying to debug an answer out of this
dynamic linking issue. I orignally found this problem when ClanLib was using
Mesa, so imagine the following configuration:

Pacman uses libclan.so, and thus all symbols between them are solved at
run time. libclan.so then uses dlopen() and dlsym() to resolve symbols
between ClanLib and libmesa.so. Everything works fine.
Then you decide to use some of GLU's functionality, which is placed in the
library libmesaglu.so (or something like that). You again use dlopen() and
dlsym() to resolve symbols between ClanLib and mesaglu - but then blam! When
you call a GLU function, the application dumps core. If you use gdb to debug
the process, you'll notice that the pointer to the glu function infact is
correct, but internally in that function, the function call to normal gl
function (libmesa.so) points right into nowhere. Somehow the dynamic linker
simply didn't resolve all the externals in the libmesaglu.so (or resolved
them wrong).

I wrote the coredumper files to prove that there actually was a serious
problem with dynamic linking using the dlsym() function. When dealing with a
large library as ClanLib, it is easy to imagine I somehow trashes somethong,
but when the program is so simple as coredumper, there can be no doubt.

> Maybe you should give that a try. Write
> functions to access the objects within your DLL and declare them extern
> "C", then link to those functions.

I'm not trying to resolve function calls between ClanLib and its
application, but rather between ClanLib and svgalib, X11, zlib, etc. And
these libs are written in C, so...

--
Magnus Norddahl
ClanSoft