[Log4cpp-devel] exception handling on SunOS when using shared log4cpp library

[Beresnev, G. <GRE...@ca...>]

$ uname -sr
SunOS 5.8

$ cat /var/sadm/softinfo/INST_RELEASE
OS=3DSolaris
VERSION=3D8
REV=3D0

$ g++ --version
2.95.3

When I compile and use static log4cpp library, all tests on Solaris =
succeed, but when I try to use
shared version, executing testPriority results in Abort and core being =
dumped:

g++ -DHAVE_CONFIG_H -I. -I. -I../include -I../include    -g -O2 -Wall =
-pedantic -c testPriority.cpp
/bin/sh ../libtool --mode=3Dlink g++  -g -O2 -Wall -pedantic  -o =
testPriority  testPriority.o ../src/liblog4cpp.la -lnsl -lsocket
g++ -g -O2 -Wall -pedantic -o .libs/testPriority testPriority.o  =
../src/.libs/liblog4cpp.so -lnsl -lsocket -R/usr/local/lib
creating testPriority
./testPriority > testPriority.testout 2>&1
Abort - core dumped
gmake: *** [testPriority] Error 134

when I load up the executable and core in gdb, I get:

$ gdb ./.libs/testPriority core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you =
are
welcome to change it and/or distribute copies of it under certain =
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for =
details.
This GDB was configured as "sparc-sun-solaris2.8"...
Core was generated by `testPriority'.
Program terminated with signal 6, Abort.
Reading symbols from =
/export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/lib=
log4cpp.so.1...
done.
Loaded symbols for =
/export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/lib=
log4cpp.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /opt/sfw/lib//libstdc++.so.2.10.0...done.
Loaded symbols for /opt/sfw/lib//libstdc++.so.2.10.0
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from =
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
#0  0xff11a034 in _libc_kill () from /usr/lib/libc.so.1

(gdb) bt
#0  0xff11a034 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff0b512c in abort () from /usr/lib/libc.so.1
#2  0xff22231c in __default_terminate () from =
/opt/sfw/lib//libstdc++.so.2.10.0
#3  0xff22234c in __terminate () from /opt/sfw/lib//libstdc++.so.2.10.0
#4  0xff222e64 in throw_helper (eh=3D0xff254a64, pc=3D0xff362b3b, =
my_udata=3D0xffbef620, offset_p=3D0xffbef61c)
   from /opt/sfw/lib//libstdc++.so.2.10.0
#5  0xff22306c in __throw () from /opt/sfw/lib//libstdc++.so.2.10.0
#6  0xff362b3c in log4cpp::Priority::getPriorityValue =
(priorityName=3D@0xffbef940) at Priority.cpp:65
#7  0x112d8 in main (argc=3D138240, argv=3D0xffbef9bc) at =
testPriority.cpp:13

like I mentioned before, this problem didn't exist when I used static =
version of log4cpp library. After doing some newsgroup
searching, I've found the following:=20

"It turns out that libtool uses "ld" instead of "g++" to create shared =
libraries. This causes problems for packages like cppunit that rely on =
libtool to create shared libraries that are written in C++. The g++ =
linker automatically adds special prolog code to the .so that takes care =
of passing exceptions across the shared library interface. If you link =
the library with "ld", then the prolog code is not added and exceptions =
cause an abort if they reach a point in the call stack that crosses out =
of the current shared library. This is really a bug in the libtool =
distributed with C++ libraries. The simplest work around is to relink =
the library using g++ instead of ld. Perhaps the maintainers of libtool =
will release a patch that addresses this issue."
I then had a look at the libtool website, and there found this:
"Creating libraries of C++ code should be a fairly straightforward =
process, because its object files differ from C ones in only three ways: =

	Because of name mangling, C++ libraries are only usable by the C++ =
compiler that created them. This decision was made by the designers of =
C++ in order to protect users from conflicting implementations of =
features such as constructors, exception handling, and RTTI.=20
	On some systems, the C++ compiler must take special actions for the =
dynamic linker to run dynamic (i.e., run-time) initializers. This means =
that we should not call `ld' directly to link such libraries, and we =
should use the C++ compiler instead.=20
	C++ compilers will link some Standard C++ library in by default, but =
libtool does not know which are these libraries, so it cannot even run =
the inter-library dependence analyzer to check how to link it in. =
Therefore, running `ld' to link a C++ program or library is deemed to =
fail. However, running the C++ compiler directly may lead to problems =
related with inter-library dependencies.=20
The conclusion is that libtool is not ready for general use for C++ =
libraries. You should avoid any global or static variable =
initializations that would cause an "initializer element is not =
constant" error if you compiled them with a standard C compiler"
I'm just wondering what the most appropriate solution would be under the =
circumstances ... modifying 'configure' to ensure
C++ compiler (and not ld) gets used for creation of shared C++ =
libraries?

Greg