[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dlsym() and C++



Quoting Jeff Read (bitwize@geocities.com):

> Why are you attempting to use dlopen() to access libMesaGLU.so? These
> libraries are generally intended to be used with an -l flag on the
> linker's command line. Part of ld's function is to resolve all the
> externals to libraries as they are needed. ld may have no way of
> determining whether or not MesaGLU is dependent upon MesaGL. Libraries
> are often not linked against one another as one would expect.

I want to have a libclan.so that includes all the implementations at once.
Including the svgalib, x11, mesa, glide, ggi, ptc and sdl (not all have been
written yet, you get the idea). But very importantly, I do NOT want users of
ClanLib to be forced to download all those different gfx libs. ld cannot
provide this service, because it requires all the external symbols to be
solved.
Sure I could let all users of ClanLib download the library and compile it so
it fits their system perfectly, but that isn't very service minded - and
the typical game player doesn't want to be bothered with such kinds of
things. He just wants to play.
Another important thing is, that the game developer want the player to just
download his executeable, and then start playing - so I find many good
reasons to have this feature.

> Maybe if you did a dlopen on libMesaGL.so with the flags RTLD_NOW and
> RTLD_GLOBAL before opening libMesaGLU.so, it would resolve properly.
> RTLD_NOW resolves all external symbols immediately. RTLD_GLOBAL makes
> those symbols visible to other shared libs that may be loaded.
> 
> Hope this helps :)

Dammit - someone just hacked my linux box while writing this!!!! Dammit
those hackers...!

Time to do a security update...

--
Magnus Norddahl
ClanSoft