On Tue, 6 Oct 2015, Matthias Apitz wrote:
We learned that the exception handling in our application-servers (C++
written) does not work. We reduced the problem to the following example
code:
#include <iostream>
using namespace std;
int main(int argc, const char **argv)
{
cout << "work:Start" << endl;
try {
throw 7;
}
catch (int ex) {
cout << "Caught exception int: " << ex << endl;
}
catch (...) {
cout << "Caught exception ..." << endl;
}
cout << "work:Ende" << endl;
}
and compile it with:
$ uname -a
SunOS srap01dxle 5.10 Generic_150400-17 sun4u sparc SUNW,SPARC-Enterprise
$ /usr/local/gcc-492/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-492/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-492/libexec/gcc/sparc-sun-solaris2.10/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: ./configure --prefix=/usr/local/gcc-492 --with-gmp=/usr/local/gmp-600 --with-mpfr=/usr/local/mpfr-313 --with-mpc=/usr/local/mpc-102 --without-isl --without-cloog
Thread model: posix
gcc version 4.9.2 (GCC)
$ /usr/local/gcc-492/bin/gcc -o work work.C -L/usr/local/gcc-492/lib -lstdc++
$ ldd ./work
libstdc++.so.6 => /usr/local/gcc-492/lib/libstdc++.so.6
libc.so.1 => /lib/libc.so.1
libm.so.2 => /lib/libm.so.2
librt.so.1 => /lib/librt.so.1
libgcc_s.so.1 => /usr/local/gcc-492/lib/libgcc_s.so.1
libaio.so.1 => /lib/libaio.so.1
libmd.so.1 => /lib/libmd.so.1
/platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1
/lib/libm/libm_hwcap1.so.2
$ ./work
work:Start
terminate called after throwing an instance of 'int'
Abort - core dumped
Last time I heard about similar problems on Solaris, it was because some
exception-related symbols appear in both libc and libgcc_s but are not
compatible, so it is important that libgcc_s be loaded first. IIRC a
libtool update made the problem much more rare.
--
Marc Glisse
