python35 @3.5.2_0 fails to build with macosx_deployment_target 10.7

[help@…]

I'm running OS X 10.10.5 and Xcode 7.2.1 (latest available for Yosemite), tested also with Xcode 7.0.1. Error message is as follows (full log is attached):

:info:build DYLD_FRAMEWORK_PATH=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.2 ./python.exe -E -S -m sysconfig --generate-posix-vars ;\
:info:build     if test $? -ne 0 ; then \
:info:build             echo "generate-posix-vars failed" ; \
:info:build             rm -f ./pybuilddir.txt ; \
:info:build             exit 1 ; \
:info:build     fi
:info:build /bin/sh: line 1: 25271 Killed: 9               DYLD_FRAMEWORK_PATH=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python35/python35/work/Python-3.5.2 ./python.exe -E -S -m sysconfig --generate-posix-vars
:info:build generate-posix-vars failed
:info:build make: *** [pybuilddir.txt] Error 1

This happens only with deployment target set to 10.7, any other value (say 10.6, 10.8 or not set) works fine. It looks like some OS X security measure kicks in and kills python.exe, but running "sudo spctl --master-disable" didn't change anything. In /var/log/system.log I see the following message:

taskgated[97]: no signature for pid=25271 (cannot make code: UNIX[No such process])

All in all this looks like Xcode compiler or/and linker bug, but I would welcome any advice on this issue.

[help@…]

python27 builds fine, python34 and python36 fails the same.

[parafin]

workaround

[parafin]

Looks like usage of -stack_size option when MACOSX_DEPLOYMENT_TARGET is set to 10.7 triggers a bug in linker. Just removing it helps, but I'm not sure of consequences (see comments above changed line in patch file).

[larryv (Lawrence Velázquez)]

We don’t support changing the deployment target globally, so I recommend that we not apply any workarounds. This should be reported upstream if it has not already been.

[ned-deily (Ned Deily)]

Appears to be a duplicate of ​http://bugs.python.org/issue21381 which has languished.

[ryandesign (Ryan Carsten Schmidt)]

Replying to larryv:

We don’t support changing the deployment target globally

I would say that we do support it, which is to say that MacPorts can do it and it is a reasonable thing for a user to try to do, however because so few users do it, there are likely to be problems encountered when using it that will need to be investigated and fixed on a port by port basis.

Has duplicate #60279 that shows it's still an issue in python38.

[jmroot (Joshua Root)]

The stack size increase was added in the first place because significant amounts of real-world code was hitting the recursion limit. So removing it isn't an option. I don't know that there's anything we can do here unless someone figures out a better workaround (and that should certainly be submitted upstream as well.)