[Python-Dev] GCC version compatibility (original) (raw)

David Abrahams dave at boost-consulting.com
Fri Jul 8 17:15:57 CEST 2005

[Christoph, please keep the python-dev list in the loop here, at least until they get annoyed and decide we're off-topic. I think this is crucial to the way they package and deliver Python]

Christoph Ludwig <cludwig at cdc.informatik.tu-darmstadt.de> writes:

On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote:

"Martin v. Löwis" <martin at v.loewis.de> writes:

> David Abrahams wrote: >> I'm wondering if there has been a well-known recent change either in Python >> or GCC that would account for these new reports. Any relevant >> information would be appreciated. [...] > Python is linked with g++ if configure thinks this is necessary Right. The question is, when should configure "think it's necessary?" Just to add to the confusion... I encountered the case that configure decided to use gcc for linking but it should have used g++. (It is Python PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with g++ 3.4.2.) Background: The description of --with-cxx in the README of the Python 2.4.1 source distribution made me think that I need to configure my Python installation with --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++ extensions built with this compiler. (That was possibly a misunderstanding on my part,

AFAICT, yes.

but Python should build with this option anyway.)

configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when linking the python executable due to an unresolved reference to _gxxpersonalityv0. I had to replace CC by CXX in the definition of LINKCC to finish the build of Python. When I looked into this problem I saw that configure in fact builds a test executable that included an object file compiled with g++. If the link step with gcc succeeds then LINKCC is set as above, otherwise CXX is used. Obviously, on my system this test was successful so configure decided to link with gcc. However, minimal changes to the source of the test program caused the link step to fail. It was not obvious to me at all why the latter source code should cause a dependency on the C++ runtime if the original code does not. My conclusion was that this test is fragile and should be skipped.

Sounds like it. I have never understood what the test was really checking for since the moment it was first described to me, FWIW.

If Python is built with --with-cxx then it should be linked with CXX as well.

U betcha.

I gather from posts on the Boost mailing lists that you can import Boost.Python extensions even if Python was configured --without-cxx.

Yes, all the tests are passing that way.

(On ELF based Linux/x86, at least.) That leaves me wondering

* when is --with-cxx really necessary?

I think it's plausible that if you set sys.dlopenflags to share symbols it might end up being necessary, but IIRC Ralf does use sys.dlopenflags with a standard build of Python (no --with-cxx)... right, Ralf?

* what happens if I import extensions built with different g++ versions? Will there be a conflict between the different versions of libstdc++ those extensions depend on?

Not unless you set sys.dlopenflags to share symbols.

It's conceivable that they might conflict through their shared use of libboost_python.so, but I think you have to accept that an extension module and the libboost_python.so it is linked with have to be built with compatible ABIs anyway. So in that case you may need to make sure each group of extensions built with a given ABI use their own libboost_python.so (or just link statically to libboost_python.a if you don't need cross-module conversions).

HTH,

Dave Abrahams Boost Consulting www.boost-consulting.com

More information about the Python-Dev mailing list