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. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
