Exception-Catching with gcc 4.x does not work on SunOS SPARC

[Marc Glisse]

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