for various tasks, the just built python for the host is used. this patch searches for a suitable python for the build machine and uses it for the build.

+	case $$MAKEFLAGS in *s*) quiet=-s; esac; \
Should be quiet=-q.  make -s → setup.py -q

the updated patch addresses:

 - fix typo mentioned in msg156044

 - don't use the host python during build and installation

 - for include files and libraries, use the search directories
   provided by gcc, and only fall back to hard coded
   directories for native builds.

 - fix the dpkg-architecture call for cross builds

 - pass the --host and --build arguments to the libffi build

 - fix the pydebug check, taken from issue #3871.

The patch introduces two new variables, which are set in the environment for cross builds:

 - _PROJECT_BASE is used by Lib/sysconfig.py to point to the
   current source, while using the python3 interpreter of the
   build machine, so that the Makefile and the pyconfig.h are
   read from the current sources.

 - _HOST_PLATFORM is used to override the get_platform calls
   in Lib/sysconfig.py, Lib/distutils/utils.py and setup.py.
   Yes, distutils is frozen, however this change shouldn't
   break anything else. It only relies on one environment
   variable _HOST_PLATFORM, so if this is an issue, then the
   name can be obfuscated even more.

tested with a cross build for arm-linux-gnueabihf on x86_64-linux-gnu, and a native build.

New changeset b285ec79e5de by Matthias Klose in branch 'default':
previous patch needs patch from issue #14330
http://hg.python.org/cpython/rev/b285ec79e5de

Patch looks okay as it contains no important changes to distutils, the compilers or any big part; it’s the sort of changes that have been accepted to fix Mac issue or support multiarch on Debian.  I would prefer safer names for environment variables though, for example PYTHON_BUILD_HOST_PLATFORM instead of just _HOST_PLATFORM (unless this is not specific to the Python build process but used by all cross-compiling builds).

PYTHON_BUILD_HOST_PLATFORM is confusing/misleading. I'll use _PYTHON_HOST_PLATFORM (with the leading underscore to mark it somehow internal).

New changeset cfbe51e66749 by doko in branch 'default':
- Issue #14330: For cross builds, don't use host python, use host search paths
http://hg.python.org/cpython/rev/cfbe51e66749

applied

+if "_PROJECT_BASE" in os.environ:

Can you use _PYTHON_PROJECT_BASE here?  Thanks.

(BTW it would be nice if you could mark the bugs for which you did commits as closed+fixed+committed.)

New changeset 86ac09f118be by doko in branch 'default':
- Issue #14330: For cross builds, don't use host python, use host search paths
http://hg.python.org/cpython/rev/86ac09f118be

now renamed, add added the news entry

New changeset 7955d769fdf5 by doko in branch 'default':
- Issue #14330: Don't derive the include and library search dirs
http://hg.python.org/cpython/rev/7955d769fdf5

The last changeset (7955d769fdf5) caused some problem on my machine.
Before the changeset I was getting:

Python build finished, but the necessary bits to build these modules were not found:
_bz2               _curses            _curses_panel   
_dbm               _gdbm              _lzma           
_tkinter                                              
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

After 7955d769fdf5 I get:

Python build finished, but the necessary bits to build these modules were not found:
_bz2               _curses            _curses_panel   
_dbm               _gdbm              _lzma           
_sqlite3           _ssl               _tkinter        
readline           zlib                               
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

I'm on an ubuntu 12.04 machine.

I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

just back in DE today, but still travelling. Won't be able to look at this before late Monday.

Everything is still building happily for me on Fedora, so I suggest looking at the Debian/Ubuntu multiarch support (which is the origin of the dpkg-architecture call).

Background in http://bugs.python.org/issue11715

Matthias, any comments?

Matthias: ping.  I don't want to hold up beta2 indefinitely.  In order to resolve this blocker, we will revert the batch of cross-compiling patches in a few days if there is no progress here.

these are all extensions, which use headers and libraries installed in multiarch paths, which I think are not found in this case. If the dpkg-dev package isn't installed, please install it and recheck. So this issue should be closed, maybe with the ma.diff patch applies as in issue #15426.

and please make sure that other build dependencies are installed as well:

 sudo apt-get build-dep python3.2 (on 12.04/precise)

 sudo apt-get build-dep python3.3 (on 12.10/quantal)

afaics, msg166444 doesn't have to do anything with the cross build issue, but a missing build dependency (here: dpkg-dev).

Ezio?

Installing dpkg-dev indeed resolved the issue for me on Debian Wheezy,
but msg166444 said that the problem appeared in 7955d769fdf5. 

So was dpkg-dev already an official dependency before 7955d769fdf5
or not?

With ma.diff from #11715 dpkg-dev is indeed not required (checked
on Wheezy).

On another Ubuntu 12.04 machine with dpkg-dev installed I didn't have any issue.  Once I removed dpkg-dev I was able to reproduce the issue again.
Applying ma.diff from #11715 solves the issue, with and without dpkg-dev installed.

committed the ma.diff from #11715, msg167680.