python35: doesn't work with Xcode 4

[mojca (Mojca Miklavec)]

Python 3.5.0 fails to build on 10.7.

See: ​https://bugs.python.org/issue24844

Maybe we could temporary add some compiler blacklisting code

[mojca (Mojca Miklavec)]

I just wanted to add that configure.compiler=macports-clang-3.4 seems to work.

[su-v]

Cc Me!

[mojca (Mojca Miklavec)]

Apart from blacklisting clang <= 425, a trivial post-configure patch would be to replace

#define HAVE_BUILTIN_ATOMIC 1

with

#undef HAVE_BUILTIN_ATOMIC

in pyconfig.h.

(I added some other weird suggestions to the upstream bug tracker. Ideally the configure check should be improved, but I'm not sure how.)

[dgonyier (Dwaine Gonyier)]

For what it is worth, this is how I got the python 3.5.2 port to build on PowerBook G4 running Leopard:

port install python35@+readline config.compiler=macports-clang-3.4

[dbevans (David B. Evans)]

Also reported in #51963 after the original issue there was resolved. CCing reporter of that ticket. Is there any reason why this can't be resolved using one or more of the fixes suggested above?

[larryv (Lawrence Velázquez)]

It’d probably be a good idea to get some kind of feedback from upstream first.

[dbevans (David B. Evans)]

Replying to larryv@…:

It’d probably be a good idea to get some kind of feedback from upstream first.

That's all well and good but it hasn't happened in the 10 months that this ticket has been open and 10.7 users still have a broken port. Since several users have confirmed that using clang-3.4 is a valid work around, wouldn't it be in our users' interests to go with that option now and sync with upstream if and when they get around to responding. Doesn't seem like an issue that has much traction upstream.

[mojca (Mojca Miklavec)]

I attached a stupid patch to the upstream ticket. We can use that one for now (or rather a patch for configure file) or just blacklist the relevant compilers.

[ned-deily (Ned Deily)]

I agree that going with with the use of clang-3.4 is the most expedient and probably best overall solution. We at upstream do not have much incentive to add more special configuration code option for the very small (and diminishing) set of users who might be affected by this. Xcode 4 has always been problematic for Python 3. Fortunately, there are standard options for 10.6 (use Xcode 3.2.6) and for 10.8 (use Xcode 5.x). It's just 10.7 that doesn't have a good Apple-provided alternative.

[dbevans (David B. Evans)]

Replying to nad@…:

I agree that going with with the use of clang-3.4 is the most expedient and probably best overall solution. We at upstream do not have much incentive to add more special configuration code option for the very small (and diminishing) set of users who might be affected by this. Xcode 4 has always been problematic for Python 3. Fortunately, there are standard options for 10.6 (use Xcode 3.2.6) and for 10.8 (use Xcode 5.x). It's just 10.7 that doesn't have a good Apple-provided alternative.

Thanks for your reply. I agree with this assessment -- better to blacklist the Xcode 4 compilers than hack up the python3 code. Jyrki hasn't responded, so I assume there is no objection there. Mojca, since you opened the ticket and have a 10.7 test platform, do you want to do the honors? I assume that this is an issue for most if not all the python3x ports.

[mojca (Mojca Miklavec)]

Since you asked me to do the commit, I added the patch rather than blacklisting the compiler to avoid the need for installing an additional compiler, r150998. It doesn't make much of a difference either way. Most MP users probably need to have clang 3.4 installed anyway.

This has only been a problem since some version of 3.5 (the initial RCs comiled ok).

As far as the upstream is concerned: the configure script contains nearly 18k lines already. I don't think that adding 10 additional lines would add so much more complexity. The source code doesn't need any changes at all, one only needs to correct an "incomplete test" for a feature. I agree that the number of Lion users is declining and that this is not a problem in MacPort where blacklisting a compiler is super easy. But on the other hand the patch is not too ugly and I don't see any good reason to refuse patching the upstream sources (other than perhaps saying that the patch could/should be improved). Of course, if Python switches to C++11, this will be a different story.

[mojca (Mojca Miklavec)]

I forgot about python36. I committed the same fix for version 3.6 in r151100.