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

["Martin v. Löwis"]

Christoph Ludwig wrote:
> My point is: The test implemented in the 2.4.1 configure script gives a wrong
> result if your platform happens to be x86 Linux with ELF binaries and 
> g++ 4.0. 

Point well taken.

>>It is only recent changes to g++ that break the test, namely the
>>introduction of this __gxx_personality_v0 thing.
> 
> 
> The test broke due to a change in GCC 4.0, but the "__gxx_personality_v0
> thing" was introduced long before. It is merely a symptom. I ran the tests
> with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:

As I say: it's a recent change (GCC 3.3 *is* recent).

>>You are assuming implementation details here. 
> 
> I am not aware of any rule that makes the following program ill-formed:

And I didn't suggest that such a rules exists. Your proposed
modification to the test program is fine with me.

> But I digress. It's not that important for our discussion whether a C++
> compiler must / should / is allowed to add exception handling code to the
> call of an extern "C" function. The point is that some do *unless* they see
> the function definition. I contend the test involving two TUs matches more
> closely the situation with ccpython.cc than the current test.

Maybe. For Python 2.4, feel free to contribute a more complex test. For
Python 2.5, I would prefer if the entire code around ccpython.cc was
removed.

> Instead of having yet another test in configure.in that may break on a new
> platform and that needs maintenance wouldn't it be better to assume that
> --with-cxx implies linking with the C++ compiler and telling users how to
> override this assumption? Would it cause so much inconvenience to users
> provided the explanation of --with-cxx in the README would be modified?

*If* the configure algorithm is modified, I think I would prefer if the
feature was removed entirely.

> In Python 2.4.1, the help message says "enable C++ support". That made me use
> this option even though it turned out it is not necessary on my platform.

For 2.4.2, things should essentially stay the way they are, except
perhaps for fixing bugs. For 2.5, more radical changes are possible.

Regards,
Martin