Peter, a) virtual destructor: did not change anything b) using static libraries: works fine! Hm. I have not had such a problem before and I we are using quite a few shared objects that throw exception which are caught elsewhere. Maybe this is related to nm not seeing any symbols? $ nm lib/libboost_thread-gcc42-mt-1_36.so.1.36.0 nm: lib/libboost_thread-gcc42-mt-1_36.so.1.36.0: no symbols We are using the gcc option -fvisibility=hidden for our own projects and we require to specify classes or functions which we explicitly want to be exported by shared objects by putting DSOEXPORT in front of the classname. It is defined in the following way: #ifdef _MSC_VER #ifdef BUILDING_DSO #define DSOEXPORT __declspec(dllexport) #else #define DSOEXPORT __declspec(dllimport) #endif #define DSOLOCAL #else #define DSOEXPORT __attribute__ ((visibility("default"))) #define DSOLOCAL __attribute__ ((visibility("hidden"))) #endif Exceptions declared and thrown in shared objects have to use DSOEXPORT in order to be catched elsewhere. Regards, Roland Peter Dimov wrote:
$ ./src/BoostThreads Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else
...
libboost_thread-gcc42-mt-1_36.so.1.36.0 =>
Can you try the same test with the static Boost.Threads library? Maybe your configuration doesn't support catching non-polymorphic exceptions thrown across .so boundaries. You could also try adding a virtual destructor to thread_interrupted. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users