dlopen flags proposal

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dlopen flags proposal

Jose Luis Hidalgo Valiño
Hi All,
  I have problem with the way lua open libraries using dlopen:

static void *ll_load (lua_State *L, const char *path) {
 void *lib = dlopen(path, RTLD_NOW);
 if (lib == NULL) lua_pushstring(L, dlerror());
 return lib;
}

I need lua to use the flag RTLD_GLOBAL and I want my library to be
loaded in a standard lua interpreter. I don't know if anyone else had
problems with this, but I'm proposing change dlopen using the same
approximation as python:

(this is in http://docs.python.org/lib/module-sys.html)
setdlopenflags( n)   Set the flags used by the interpreter for
dlopen()   calls, such as when the interpreter loads extension
modules.  Among   other things, this will enable a lazy resolving of
symbols when   importing a module, if called as sys.setdlopenflags(0).
To   share symbols across extension modules, call as
sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)

In this way dlopen could be used as now, and with very little change
user will be able to manage how libraries are loaded.

By the way... I will need to show an error ("this can not be uses in a
standard lua interpreter, please change line 69 of loadlib.c  with
RLD_NOW|RTLD_GLOBAL")  :P

Best regards,
   Jose L.

PD: Related threads :
http://lua-users.org/cgi-bin/namazu.cgi?query=RTLD_NOW&idxname=lua-l&max=20&result=normal&sort=score

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


Reply | Threaded
Open this post in threaded view
|

Re: dlopen flags proposal

Luiz Henrique de Figueiredo
> 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

Reply | Threaded
Open this post in threaded view
|

Re: dlopen flags proposal

Jose Luis Hidalgo Valiño
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 <[hidden email]> 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 ----


Reply | Threaded
Open this post in threaded view
|

Re: dlopen flags proposal

Luiz Henrique de Figueiredo
> I'm working in a project that uses a lot of C++ RTTI for introspection,

I see; your request makes more sense now. Well, in this case I suggest
that you simply change your copy of loadlib.c to use RTLD_GLOBAL.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: dlopen flags proposal

Jose Luis Hidalgo Valiño
Hi Luiz,
   Actually I have the standard lua.c interpreter linked with the
library and thats solves the problem too. The mail was a request for
make more flexible lua in future revisions, maybe you can consider to
allow the user specify which flags to use at dlopen in runtime from
the interpreter (like python does) or directly use RTLD_GLOBAL.

Cheers,
  Jose L.


On 11/11/06, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> I'm working in a project that uses a lot of C++ RTTI for introspection,

I see; your request makes more sense now. Well, in this case I suggest
that you simply change your copy of loadlib.c to use RTLD_GLOBAL.
--lhf



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