Jeff Epler wrote: > If we change the linker back to gcc, not g++, will it work if extension > module 1 gets linked with libstdc++ A and ABI Q, and extension module 2 > gets linked with libstdc++ B and ABI Z?
The problem is that it won't link at all. Compiling Modules/ccpython.o using g++ creates (in some installations) a reference to libgcc functions that won't be resolved unless you also link using g++. This is because libgcc was split into two libraries, and only one of them gets automatically linked when linking with gcc; the missing symbol is in the other library which only gets linked automatically when linking with g++. > What if a built-in module is written in C++, as it might be for some > people embedding C++? (this will force use of g++ as the linker, right?) Right. If those people also use dynamic extensions, they should make sure that those link against the same libstdc++. > PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core > machine don't list libstdc++ in `rpm -q --requires python' or `ldd > /usr/bin/python'. I don't see a patch that would change Python's > behavior in the SRPM, though. I wonder what the difference is between > my FC2 and the other systems... One solution/work-around is to configure Python with --without-cxx. Then ccpython.cc won't be used, and all compiling and linking is done using gcc. Whether or not this would still allow for extension modules to use C++ depends on the platform; on Linux, it will. I believe Linux distributors normally build Python with --without-cxx. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com