Re: dlopen flags proposal

["Jose Luis Hidalgo" <joseluis.hidalgo@...>]

Hi Luiz,
   I'm working in a project that uses a lot of C++ RTTI for
introspection, Its a bit complicated to explain (and even more because
of the language :P). Basically the code I'm loading have a function
that loads its own libraries as well:

require("libosgLua") -- > that loads my library
osgLua.load("osg")  --> this functions internally load another plugin (library)
osgLua.load("osgGA")
osgLua.load("osgText")
osgLua.load("osgProducer")

That works, but when the introspection engine tries to compare
std::type_info it fails:

typeid(MyClass) == introspectionEngine::getTypeInfo("MyClass")  (FAILS)

the type_info comparison works by comparing pointers, if the returned
pointer by tyepid() and my classs are not the same it considers that
they are different types (and thats were I have the problem, because
they should be the same type)

It fails because loading without RTLD_GLOBAL creates two areas for
RTTI instead of one, so the comparison between type infos fails.
Without RTLD_GLOBAL I have two representations for the same type_info
and that breaks the way the introspection engine works.

I expect that to clarify more or less why "I" need RTLD_GLOBAL...

(from the http://gcc.gnu.org/faq.html, cut-and-paste):

dynamic_cast, throw, typeid don't work with shared libraries:

The new C++ ABI in the GCC 3.0 series uses address comparisons, rather
than string compares, to determine type equality. This leads to better
performance. Like other objects that have to be present in the final
executable, these std::type_info objects have what is called vague
linkage because they are not tightly bound to any one particular
translation unit (object file). The compiler has to emit them in any
translation unit that requires their presence, and then rely on the
linking and loading process to make sure that only one of them is
active in the final executable. With static linking all of these
symbols are resolved at link time, but with dynamic linking, further
resolution occurs at load time. You have to ensure that objects within
a shared library are resolved against objects in the executable and
other shared libraries.

   * For a program which is linked against a shared library, no
additional precautions are needed.
   * You cannot create a shared library with the "-Bsymbolic" option,
as that prevents the resolution described above.
   * If you use dlopen to explicitly load code from a shared library,
you must do several things. First, export global symbols from the
executable by linking it with the "-E" flag (you will have to specify
this as "-Wl,-E" if you are invoking the linker in the usual manner
from the compiler driver, g++). You must also make the external
symbols in the loaded library available for subsequent libraries by
providing the RTLD_GLOBAL flag to dlopen. The symbol resolution can be
immediate or lazy.


Cheeers,
   Jose L.




On 11/10/06, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
> > I need lua to use the flag RTLD_GLOBAL
>
> Why?  See the discussion below, which was about RTLD_LAZY but applies to
> RTLD_GLOBAL as well:
>
> http://lua-users.org/lists/lua-l/2004-09/msg00516.html
> http://lua-users.org/lists/lua-l/2004-09/msg00484.html
>
> --lhf


--
 Jose L. Hidalgo Valiño (PpluX)
 ---- http://www.pplux.com ----