Menu
▾
▴
Re: [Log4cpp-devel] exception handling on SunOS when using shared log4cpp library
|
From: Bastiaan B. <bas...@li...> - 2003-03-20 23:35:52
|
Hi Greg, There have been positive reports about linking log4cpp with newer CVS revisions of libtool. See the 'linking issues' thread on the 'Open Discussion' forum last October. Unfortunately these C++ link improvements have not been put into a libtool release and consequently are not in log4cpp yet. Good luck, Bastiaan On Thu, 2003-03-20 at 23:28, Beresnev, Greg wrote: > $ uname -sr > SunOS 5.8 > > $ cat /var/sadm/softinfo/INST_RELEASE > OS=Solaris > VERSION=8 > REV=0 > > $ 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=link 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/liblog4cpp.so.1... > done. > Loaded symbols for > /export/home/sso/builds/obj/sol5.8/log4cpp/log4cpp/tests/../src/.libs/liblog4cpp.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=0xff254a64, pc=0xff362b3b, > my_udata=0xffbef620, offset_p=0xffbef61c) > 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=@0xffbef940) at Priority.cpp:65 > #7 0x112d8 in main (argc=138240, argv=0xffbef9bc) 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: > > "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. > > 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. > > 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. > > > 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 -- Bastiaan Bakker <bas...@li...> |
