[C++-sig] [Python-Dev] GCC version compatibility

[David Abrahams]

[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
> __gxx_personality_v0. 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