Andrea Vedaldi <[EMAIL PROTECTED]> writes: > I'm developing some C++ modules for an engineering software called MATLAB. > I have a very annoying problem that prevents C++ exceptions to work properly.
This is somewhat explained in the http://gcc.gnu.org/faq.html#dso and just figured in the "dynamic_cast problem" thread in this same newsgroup. > 1) Modules (MEX-files) are loaded dynamically by MATLAB by dlopen() Probably without RTLD_GLOBAL ... > 2) All MEX-files include a common dynamic shared library (libvl.so) They probably don't "include it", but rather have it as a direct dependency. > 3) The shared library throws instances of a certain class > VL::Exception which are (or should) be intercepted by the MEX-files. ... > Now: > - when the FIRST MEX-file is loaded (by MATLAB calling dlopen()), > libvl.so is loaded as well > - the weak typeinfo symbols for VL::Exception are correctly merged > - throws of VL::Exception from libvl.so are correctly intercepted by > the MEX file > > But: > - when a SECOND MEX-file is loaded (dlopen() again) libvl.so is already loaded > - the weak typeinfo symbol for VL::Exception in the second MEX-file is > NOT merged (why?) Because libvl.so was loaded as part of dlopen() without RTLD_GLOBAL, and so its symbols have not been added to the list of symbols available to other dlopen()ed libraries. > - throws of VL::Esception from libvl.so terminate() the second MEX-file > > I managed to let it work as follows: > - I set LD_PRELOAD=libvl.so BEFORE launching MATLAB > - in which case all weak typeinfo symbols get merged consistently for > all calls of dlopen() as libvl.so gets loaded first Another possible workaround is to explicitly call dlopen("libvl.so", RTLD_LAZY|RTLD_GLOBAL) from every MEX-file. I was able to replicate the behaviour you described on a trivial test case, and calling dlopen(..., RTLD_GLOBAL) fixes the crash in that test case. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
