Re: shared library RTTI with gcc

["Mauro Iazzi" <mauro.iazzi@...>]

I admit I'm quite ignorant about the subject, but I could have this
issue in some of my code.
Could you please tell exactly when a new RTTI instance for a type is generated?

However I also have a problem with the behaviour of dlopen in Lua but
is not related to C++ at all.

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. But I'd also like to have
them work in standard Lua.

The solution proposed by Enrico would work. But this means loading
module A to load module B before each other module C, D, E ... which
seems quite overcomplicated.

A simple flag for package.loadlib (not to require) that allows to
specify that a specific library should export its symbols would be
perfect, would not break things around and allow more control at a
lower level on how to load libraries. One could have some ?/init.lua
that loads correctly the module, then.
Finally, loadlib already breaks strict ANSI, so it could as well
export some more capability (as opposed to require).

I see no drawbacks in this solution. Am I missing something?

mauro

On 06/10/2007, Wim Couwenberg <wim.couwenberg@gmail.com> wrote:
> > Now serious, can someone enlighten me about why RTTI needs this global
> > flag?
>
> c++ defines some implicit structures for types to support RTTI such as
> type_info instances and implicit entries in an object's virtual
> function table.  These structures are implicitly defined in *all*
> libraries that refer the type.  If different libraries link to their
> *own* instance of such structures then RTTI fails, for example a
> dyamic_cast will always fail between objects created in different
> libraries.  Not specifying RTLD_GLOBAL will keep these implicit
> structures local to the loaded library and the linker selects the
> local instance instead of the first global instance that it
> encountered.
>
> A public c++ module interface should ideally not rely on RTTI.
> However, it is not always feasible to rewrite interfaces since there's
> often a *large* existing code base that entirely depends on RTTI...
>
> On Windows the story is completely different since dll's are already
> linked.  The type info structures are explicitly placed in a shared
> administration to make RTTI work.
>
> --
> Wim
>