I've fixed up the very few missing configure bits and one issue with PYTHON_FOR_BUILD using srcdir instead of builddir. I also rolled in a simple warning fix that I ran into (the #ifdef HAVE_CHROOT added to posixmodule.c)

configured with:
$srcdir/configure --prefix=$PWD/install/darwin-x86_64/python-3.4.x --build=x86_64-linux-gnu --host=x86_64-apple-darwin11

using these compilers:
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz

and MacOSX10.7.sdk,

I can successfully build Python for Mac OS X on Linux.

I'm curious as to what value there would be in adding support for cross building an OS X variant of Python on Linux.  It seems to me that such an animal would be fragile and incomplete at best. For example, normal Python builds on OS X normally require certain OS X frameworks outside of those included with the compiler.  It's difficult enough to support native builds on a wide range of OS X releases and hardware configurations.  Why would we want to officially support this particular variant of cross building on another platform?

> It seems to me that such an animal would be fragile and incomplete at best.

There's no reason for it to be either fragile or incomplete. My cross builds have a goal of being comprehensive.

> Python builds on OS X normally require certain OS X frameworks outside of those included with the compiler.

If the user supplies the Apple Mac OS X SDK then the frameworks are correctly detected and used. To enable this, I use a set of wrapper scripts to enable this, here's the contents of x86_64-apple-darwin11-gcc:

#!/bin/sh
# Auto-generated, do not edit
/home/ray/darwin-cross/apple-osx/bin/i686-apple-darwin11-gcc -isysroot /home/ray/darwin-cross/MacOSX10.7.sdk -mmacosx-version-min=10.5 -DMAXOSX_DEPLOYEMENT_TARGET=10.5 -m64 "$@"

> Why would we want to officially support this particular variant of cross building on another platform?

There's 3 separate issues merged into this patch, general cross compilation fixes, the new darwin cross compilation feature and a few darwin warning fixes (that apply equally to cross and native). I shouldn't have done that, and am in the process of splitting this issue up so that each part can be judged in isolation. Please see the new issue I've made for the general cross compilation issues: http://bugs.python.org/issue16292
..later I'll work on a new patch for this issue.

Here's the darwin cross enabling portion. I've also removed the warnings fixes from it as they're not relevant.

The patch itself looks fine, but I wonder how useful it will be.

A small question about the patch, why this case in the cross_arch function:

+	  x86_64*darwin*)
+	    echo i386

That doesn't look correct.


Back to the more important issue of the usefulness of this patch:

* Why is cross-compiling to OSX useful at all? You still have to test
  if the output of the compilation works, and for that you need
  an OSX system.

* The patch will only help with cross-compiling C code, it won't compile
  resource files (like the NIB file in Python Launcher)

  This is not a problem right now because that project currently contains
  older NIB files that can be used for editting and running, but would
  make it harder to move to the more modern XIB files that were introduced
  with Xcode 4.

* This will make support harder, I already get support questions where
  the answer depends on the way Python was build and that will likely
  get worse with cross-compiling.

* Where would users get the SDK? I'm not a lawyer (or even familiar with
  US law), but the Xcode license seems to indicate that it can only
  be used on Apple systems.

> A small question about the patch, why this case in the cross_arch function:

From a real Mac Book Pro:

$ uname -a
Darwin MACBOOKPRO.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
$ /usr/bin/arch
i386
$ uname -m
x86_64

It would seem arch on OS X can only be used to determine PPC vs Intel (which is all that configure uses it for anyway).

> Why is cross-compiling to OSX useful at all?

Cross compiling is always useful for build engineers who have to target multiple hosts. 

> You still have to test if the output of the compilation works, and for that you need an OSX system.

Ideally yes, or a Virtual Machine with OSX on it or confidence based on the results of a previous test built with the same sources or maloader (...though maybe not, I've never personally tried maloader).

> The patch will only help with cross-compiling C code, it won't compile resource files (like the NIB file in Python Launcher)

My personal interest is for having Python embedded in other things (GDB) and using it from the command-line. Python Launcher is not part of the scope.

> This will make support harder, I already get support questions where the answer depends on the way Python was build and that will likely get worse with cross-compiling.

I'd be happy to do whatever I can to help out with this. If we could identify in the build that it was built via cross compilation somehow or have my email address in the help would that make it more palatable?

> * Where would users get the SDK? I'm not a lawyer (or even familiar with US law), but the Xcode license seems to indicate that it can only be used on Apple systems.

The users would get the SDK from being registered as a developer with Apple. As for the license, while also not being a lawyer, my interpretation is this:

In the Xcode License.rtf file (and the Command Line tools license), the relevant part is "you are granted a limited, non-exclusive license to use the Developer Software on Apple-branded computers to develop and test application and other software". This doesn't say anything about the OS that's running on said Apple-branded computer, and my interpretation is that you could install a Linux distro on an Apple computer or on a VM on an Apple computer and still be compliant with that license.