Building python on OSX Mavericks (10.9)
of Python 3.4 crashes when this is set:

MACOSX_DEPLOYMENT_TARGET=10.7

This happens with OSX 10.9.2,
all current updates installed,
as of 2014-04-28.

Demo script:
You can use my attached script to validate this error.
The script builds PySide for 16 configurations.
Exactly on Python 3.4 / OSX 10.7 it crashes.

You can easily tweak the creating loop to just build the crashing case.

Cheers -- Chris

In general, we don't test or claim to support building for a deployment target lower than the system being built on.  It's always safer to build on the same version as the deployment target.  I'll take a look at it, though.

Ned: """In general, we don't test or claim to support building for a deployment target lower than the system being built on."""

This is not convincing, because the cpython builds are always
against <$ MACOSX_DEPLOYMENT_TARGET=10.6> .

Other builds use the current OS deployment. See for instance homebrew.
My script uses them all, from a 10.9 version.
This is because I never know what users use for building, and I don't care and build just everything.

By your default builds that are uploaded, you do claim that things build for 10.6 exactly, and nothing else.

I just think that all targets for all versions should build.

Am I mistaken here?

Yes, it should be possible to build all Pythons for all recent OS X deployment targets but, normally, the safest way is to build a specific deployment target on the same OS X version; that should avoid any possibility of inadvertently linking with new features not available on the older deployment target system.  It is possible to use SDKs and tools from older versions of Xcode on newer systems to simulate building on an older system but that isn't foolproof.  Also, keep in mind that the deployment target is a minimum deployment target.  Pythons built with a deployment target of 10.n also work on 10.n+1 and generally 10.n+m, at least as long as there is no major compatibility break, like dropping support for running PPC architecture executables in 10.7.

However, the problem you've found here is an exception to that general rule.  The culprit appears to be the execution stack size increase at link time introduced by Issue18075 in b07ad4b5e349 for 3.4.0.  With the stack size increased to 16MB, when Python is built on 10.7, it seems to work fine on 10.7 but, if the same executable is moved to 10.8 or 10.9, it segfaults early in initialization.  The same behavior is observed with either debug or non-debug builds.  When the same executable is run under gdb or lldb, the interpreter doesn't segfault.  Likewise, the same behavior is seen when building on 10.8 or 10.9 and setting MACOSX_DEPLOYMENT_TARGET=10.7.  (Also, building with Xcode 4.6.3 (the current 10.7 toolchain) on 10.9 makes no difference.)

With dept target of 10.7, If the stack size increase in configure is commented out,

#LINKFORSHARED="-Wl,-stack_size,1000000 $LINKFORSHARED"

then builds with dept target of 10.7 succeed and all tests pass.  In fact, at first glance it seemed that all tests passed with a dept target of 10.9 using the current Xcode 5.1.1 build tools so it's not clear whether the original problem reported in Issue18075 still exists.

I'm puzzled by this one: thanks, Chris!  We could certainly make the stack size increase conditional but it's odd that it only seems to be a problem with 10.7.  Ronald (or anyone else): any ideas?

Ned,
thank you for locating the patch that causes the problem.
At least, I could now make my script work, built a patch
feature into it.

cheers - Chris

The problem in Issue18075 depends on the amount of C stack used on average during recursion because unlike Windows the Unix ports don't test if the end of the stack is reached but just check for a maximum recursion count.  It could well be that the problem in that issue don't happen at the moment due to small changes in either CPython or the compiler.  It is also easier to trigger the problem with a debug build.

I have no idea why the linker flag causes problems, I'd have to debug this myself.

A number of changes have been made since the initial report in 3.4 that might affect this area including as of 3.9.1 finally supporting weaklinking, that is, building on a newer version of macOS to run on older systems. Plus we no actively support systems older than macOS 10.9. I am closing this issue as out-of-date. Please re-open if the recursion segfault is still an issue with current Python and macOS versions.