lua-users home
lua-l archive

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

Hi All,
  This topic has been discussed before (with no luck)...

I'd rather a solution from lua itself, and my proposal was on the same
line as python does, let the user change those flags from inside the
script before loading a library. The worst thing for me is that this
"feature"/"bug" only affects linux/unix (not windows).


2007/10/6, Ronan Collobert <>:
> > True, RTTI should not be used as part of a library's public interface.
> > Now try to explain that to all c++ programmers out there...  :-(
> Wim, that is a very personal point of view, programmers have different
> needs. I could as well say we should all write clean C/C++ libraries,
> with all functions starting with a prefix (or using namespace with C++):
> we will then not have any names confusion problems and could open all
> libraries with RTLD_GLOBAL with no risk :)
>  > However I also have a problem with the behaviour of dlopen in Lua but
>  > is not related to C++ at all.
> I agree, Mauro. The only difference is that a part of C++ language does
> even not work if you do not use RTLD_GLOBAL.
> To avoid name collisions, gcc recommends namespaces. Quote from
> ...
> "If you are worried about different objects with the same name colliding
> during the linking or loading process, then you should use namespaces to
> disambiguate them. Giving distinct objects with global linkage the same
> name is a violation of the One Definition Rule (ODR)"
>  > I actually _want_ one of my shared object's symbols exported to all
>  > subsequent modules. This is because I have many modules with common
>  > code, that should stay in the same place.
> Yeah. In the end, if you have many clean C or C++ libraries which
> depends on each other, or C++ libraries which uses RTTI you might want
> to use RTLD_GLOBAL. If you have C or C++ libraries were you are not sure
> about name collisions (especially if it not your library) RTLD_LOCAL is
> the way. So a flag in package.loadlib would do the job, as you say.
> Ronan.

  Jose L. Hidalgo Valiño (PpluX)
  ---- ----