Bob Friesenhahn wrote: > While it has not been proven yet, I am suspecting that the failing C++ > exceptions have something to do with the way that libtool links these modules. > > Does anyone have ideas about this?
We have just solved a similar problem: our binary was linked against a shared library and when an exception was thrown in the shared library, a segmentation fault occurred in the file libgcc_s.so. It was not possible to catch the exception and continue the program. Our system is Debian, we are working on 64 bit computers with g++ 4.3.2. The problem mentioned above did not show on 32 bit (Open SuSE) systems. The reason was: the shared library was linked against another static library. Our automake mechanism told us, that this is not portable, but everything seemed to work... exception catching exceptions. Now we have changed our build mechanism. The shared library is not linked against the static library anymore. Instead we include the static library when we link our executable and suddenly everything works correctly. We can throw exceptions and catch them and there are no segmentation faults anymore. You could try the following: create a very simple example consisting just of a main file and a shared library (if you need one). Try to throw and catch exceptions. Probably you will succeed. It does not matter whether you use autoconf/libtool or not. Now increase the complexity until you arrive at your read world situation. As soon as you detect that your exception is not caught anymore you probably are very close to the solution! This way at least worked in our case... Ciao, Benjamin _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
