Re: C++ static constructors in libltdl modules [[Was Re: revised patch for glib compilation]]

[Michael Matz]

Hi,

On Tue, 20 Mar 2001, Gary V. Vaughan wrote:
> > > Nor does libltdl, since lt_dlsym() doesn't really work with the C++ name
> > > mangler.  Unfortunately, this means that the dlopen concept doesn't
> > > really port to C++.  I can imagine a hairy workaround, but I don't
> > > inflict C++ on myself outside of work *grin* =)O|
> >
> > oh, i thought someone had implemented the code in libltdl to get static
> > c++ constructors to work.
>
> Not to my knowledge, though I haven't paid as much attention to the
> multi-language branch (libtool-1.5 to be) as I would have liked.  So it may
> have gone in without my noticing...

There is no specific support in libtool for static objects (constructors
_and_ destructors that is).  It completely relies on the
compiler/linker/dl_open-mechanism of the OS to provide that support and
for most common platforms that is enough (exception is HP-UX/g++).  E.g.
on all ELF systems and g++ collect2 is collecting all
constructor/destructor calls from all .o's and stuffs them into an
initializer/finalizer list for the .so .  This then correctly is called
by dlopen/dlclose.  Note that at least Solaris and linux's ld.so have bugs
preventing it from working like one would wish.  E.g. in the presence of
static objects, one should call dlopen/close in pairs (this is normally
not necessary, as dlopen/close use refcounting), and dlopen dependent
libraries before depending ones.  Otherwise usually the program SEGV's.

For KDE I even disabled any dlclose altogether, because they gave too much
problems (not all of them caused by ld.so bugs, but also by the actual
program flow).


Ciao,
Michael.