Re: use of modules, static vs shared, and dependencies
Hi Howard, Hope you don't mind my chiming in here... mostly for the benefit of the archives, and lurkers: Howard Chu wrote: why should we go through the module-handling work for something that is statically linked into the main executable... You only have to write the module calling code once in the parent project. It accesses all the modules through the lt_dlopen APIs, and doesn't care whether the person who built the project wanted to have dso modules or preload all the modules into the same address space (or some of each). Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
postdeps empty on OpenBSD
I'm trying to link C++ code into a shared object for use as a Python module. I'm using libtool to do the linking. On Linux this works well, but on OpenBSD it fails with lots of C++ library symbols not found. The problem seems to be that on OpenBSD the shared object doesn't pull in libstdc++. Python isn't written in C++, so doesn't pull in libstdc++ either. I've found that if I explicitly link with -lstdc++ then it works on OpenBSD, which supports this theory. I could potentially just always explicitly link with -lstdc++, but I'm concerned that this could try to link in two different versions on a machine with multiple compilers installed. Comparing the generated libtool scripts on the 2 systems, I've noticed that postdeps is empty on OpenBSD. On Linux it is: postdeps="-lstdc++ -lm -lgcc -lc -lgcc" So this would seem to be on the right track. I don't entirely follow the logic which generates this, but it seems to come from the output of something like: g++ -shared -v /dev/null 2>&1|grep "\-L" On an x86 Linux box (Debian unstable) with g++ 3.3.6 this gives: /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/collect2 --eh-frame-hdr -m elf_i386 -shared /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crti.o /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/crtbeginS.o -L/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/bin/../lib/gcc-lib -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. /dev/null -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/crtendS.o /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crtn.o On an x86 OpenBSD 3.7 box with g++ 3.3.5 this gives: /usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5/collect2 --eh-frame-hdr -shared -Bdynamic -dynamic-linker /usr/libexec/ld.so /usr/lib/crtbeginS.o -L/usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5 /dev/null -lsupc++ -lgcc -lgcc /usr/lib/crtendS.o Note: -lsupc++ instead of -lstdc++. If I remove the "-shared" on OpenBSD I get -lstdc++ instead of -lsupc++. I don't know if it's relevant, but both systems have shared and static versions of libstdc++, but only static versions of libsupc++ and libgcc. The Linux system has a shared (only) libgcc_s, but the OpenBSD system doesn't have this at all. Is this a libtool issue, or should I be looking elsewhere? And please say if I need to provide more information. I don't have a small example showing the problem, though I can work on one if that's helpful. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Tue, 20 Sep 2005, Olly Betts wrote: I'm trying to link C++ code into a shared object for use as a Python module. I'm using libtool to do the linking. On Linux this works well, but on OpenBSD it fails with lots of C++ library symbols not found. You may encounter more problems even after a successful link. The problem is that static initialization (including initializing C++ exception support) may not be done correctly for C++ code loaded by a C program. It should help to use the C++ compiler to do the link rather than a C compiler. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Tue, 20 Sep 2005, Olly Betts wrote: I've carefully avoided creating static objects, so at least that shouldn't be a problem. And exceptions are at least only thrown in exceptional circumstances... If you are using the C++ standard library, there are things going on that you are normally blissfully unaware of. These may use static initialization. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Tue, 20 Sep 2005, Olly Betts wrote: Should libtool be able to link a C++ module such that it can be dlopen-ed by a C program (on platforms where this can be made to work)? Yes. Any libraries necessary for C++ programs should be applied when linking using the C++ compiler. It seems that you have encountered a case where the wrong libraries are used. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Tue, Sep 20, 2005 at 01:30:37PM -0500, Bob Friesenhahn wrote: > On Tue, 20 Sep 2005, Olly Betts wrote: > > >I'm trying to link C++ code into a shared object for use as a Python > >module. I'm using libtool to do the linking. On Linux this works > >well, but on OpenBSD it fails with lots of C++ library symbols not > >found. > > You may encounter more problems even after a successful link. The > problem is that static initialization (including initializing C++ > exception support) may not be done correctly for C++ code loaded by a > C program. Thanks for the warning. I've carefully avoided creating static objects, so at least that shouldn't be a problem. And exceptions are at least only thrown in exceptional circumstances... > It should help to use the C++ compiler to do the link rather than a C > compiler. I'm using libtool to link, and it uses a C++ compiler to do the link (at least in these two cases). Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On Tue, Sep 20, 2005 at 01:51:28PM -0500, Bob Friesenhahn wrote: > If you are using the C++ standard library, there are things going on > that you are normally blissfully unaware of. These may use static > initialization. Fair enough, a C++ Python module may simply not work on some platforms. But static initialisation does work on a number of platforms in this situation, including both Linux and OpenBSD (I've just written a small testcase to actually check). But we seem to have strayed from the problem I actually have (into problems I might potentially have!) Should libtool be able to link a C++ module such that it can be dlopen-ed by a C program (on platforms where this can be made to work)? Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
