|
From: Beresnev, G. <GRE...@ca...> - 2003-03-20 22:28:23
|
$ 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 |