Repository navigation
cross-compilation support for python build #48004
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/tarekziade'
closed_at = <Date 2013-02-02.16:51:13.100>
created_at = <Date 2008-09-01.21:49:18.597>
labels = ['type-feature', 'build']
title = 'cross-compilation support for python build'
updated_at = <Date 2013-02-06.13:27:50.032>
user = 'https://bugs.python.org/rpetrov'bugs.python.org fields:
activity = <Date 2013-02-06.13:27:50.032>
actor = 'doko'
assignee = 'tarek'
closed = True
closed_date = <Date 2013-02-02.16:51:13.100>
closer = 'rpetrov'
components = ['Cross-Build']
creation = <Date 2008-09-01.21:49:18.597>
creator = 'rpetrov'
dependencies = []
files = ['17361', '17778', '18625', '19586', '19588', '20534', '20536', '21570', '22036', '23034', '24923', '25762', '25850', '27444', '27896']
hgrepos = []
issue_num = 3754
keywords = ['patch', 'needs review']
message_count = 56.0
messages = ['72299', '77241', '98223', '105859', '108744', '110685', '114776', '127140', '132102', '133252', '136371', '136772', '136885', '136887', '136911', '136962', '136963', '136987', '137001', '142972', '155693', '155971', '155972', '155977', '155980', '156240', '161972', '162421', '162464', '164376', '164378', '164381', '164382', '164385', '164395', '164396', '164402', '164403', '164409', '164412', '164416', '166740', '171787', '172156', '174925', '174926', '174928', '175009', '180590', '180594', '180701', '181180', '181447', '181449', '181457', '181520']
nosy_count = 18.0
nosy_names = ['doko', 'wrobell', 'vapier', 'tarek', 'eric.araujo', 'rpetrov', 'Arfrever', 'devurandom', 'WhiteTiger', 'BreamoreBoy', 'python-dev', 'David.Kern', 'Greg.Hellings', 'kalev', 'marqvar', 'Ray.Donnelly', 'eudoxos', 'ambrop7']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue3754'
versions = ['Python 3.3']
Activity
wrobell commentedon May 25, 2011
Would it be possible to get list of steps required to test this patch?
What else?
rpetrov commentedon May 25, 2011
Usually this is not a question for bug-tracking system . configure ..
--host=.... will enter into cross-compilation mode. You could find more
details into respective manual.
Roumen
wrobell commentedon May 25, 2011
well, looking at the first comment, there is required more than simple read of the manual (i.e. missing config.guess/config.sub).
is anything else missing or required?
wrobell commentedon May 26, 2011
as well, by default one experiences
checking for /dev/ptmx... not set
configure: error: set ac_cv_file__dev_ptmx to yes/no in your CONFIG_SITE file when cross compiling
the workaround:
would be it ok if i add appropriate options for /dev/ptmx and /dev/ptc to this patch so we do not have to play with config.site file?
wrobell commentedon May 26, 2011
next question. when starting compilation i am getting
In file included from Include/Python.h:50,
from ./Modules/python.c:3:
Include/pyport.h:257:13: error: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"
make: *** [Modules/python.o] Error 1
how to deal with above?
wrobell commentedon May 26, 2011
looking into configure.in the above fails due to following check
AC_MSG_CHECKING(for %lld and %llu printf() format support)
the check compiles and tries to _run_ a bit of software to determine lld/llu support.
that of course fails (we are cross compiling). this is similar problem to ptmx/ptc problem (we do not know if host have support for ptmx/ptc).
i wonder if the following would be acceptable
does above sound like a solution?
rpetrov commentedon May 26, 2011
At least one is really would like to cross-compile.
worber, the config site has to look like (sample for linux i?86, i.e. intel 32 bit, as host platform)
=================================
=================================
Also with following patch into configure.in
=======================================
=======================================
merwok commentedon Aug 25, 2011
Copy-pasting of a previous comment: I see some “fix for issue #NNN is bogus” in your patch: would you open separate bug reports for those? A diff file is not a very useful way to report bugs or express opinions <wink>.
Copy-pasting of many previous comments: distutils does not get new features (cross-compilation is a new feature), please focus on packaging.
doko42 commentedon Mar 14, 2012
Roumen, do you have a newer patch which applies to the current trunk?
doko42 commentedon Mar 15, 2012
some of these changes are now available in trunk, tested with a x86_64-linux-gnu to arm-linux-gnueabihf cross build.
using bpo-14324 for configure tests which need fixes, and bpo-14327 for the use of uname in the configure script.
please feel free to open separate issues for the changes in the distutils package and the packaging package.
merwok commentedon Mar 15, 2012
Not for distutils (feature-frozen, see previous messages)
doko42 commentedon Mar 16, 2012
bpo-14330 handles not using the host python for the build
doko42 commentedon Mar 16, 2012
I'm now able to build the interpreter (and run it in qemu on the same machine), but building the extension modules fails. the build is configured as:
building 'cmath' extension
arm-linux-gnueabihf-gcc -fPIC -Wno-unused-result -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -I. -I/usr/include/arm-linux-gnueabihf -I/usr/local/include -I/usr/include/python3.3m -c cmathmodule.c -o build/temp.linux-x86_64-3.3/cmathmodule.o
arm-linux-gnueabihf-gcc: error: cmathmodule.c: No such file or directory
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.
the source files are not found (srcdir != builddir), the patch from rpetrov talks about:
+# revert patch from bpo-7880 :
+# - the test case (from bpo-7880) works for me
+# - realpath break cross compilation
+# => so lets use abspath again ;)
+# NOTE "Issue bpo-6612: Fix site and sysconfig to catch os.getcwd() error,
+# eg. if the current directory was deleted." replase all occurrence of
+# realpath with _safe_realpath. Instead to update _safe_realpath to use
+# abspath the cross-compilation revert all!
but I'm running out of time, and won't work on this for the next two weeks.
rpetrov commentedon Mar 18, 2012
I cannot test arm build due to bpo-12010
mingwandroid commentedon May 30, 2012
Hi Roumen,
Many thanks for your patches, I've been using a 2.7.1 version of your patches for Python integration with GDB (pretty-printing) of my own version of the Android NDK for ages now (part of the Necessitas Qt project) and I really appreciate your efforts in this area. I've recently started looking into cross compilation of Python as I want to build everything on Linux and hopefully I can be useful in this effort.
What you said about wchar_t on Android is true on API level <= 8, but fixed for >8. See:
https://groups.google.com/group/android-ndk/browse_thread/thread/e40e3fd241e72d3f?pli=1
To test this:
compile failure:
arm-linux-androideabi-gcc -I$NDK/platforms/android-8/arch-arm/usr/include/ -S test.c
test.c:2: error: size of array 'bytes' is negative
compile success:
arm-linux-androideabi-gcc -I$NDK/platforms/android-9/arch-arm/usr/include/ -S test.c
I've attached a version of your latest patch re-made against released 3.3.0a2. I've also done the same thing for your MinGW patch at http://bugs.python.org/issue3871
I'll follow up shortly with a patch that addresses some of the remaining issues with cross building for MinGW on Linux (and also the beginnings of Darwin on Linux). It'll be attached to http://bugs.python.org/issue3871 though as it's more specific to MinGW than general cross.
rpetrov commentedon Jun 6, 2012
About Android issue with wchar still is applicable. So issue is not exactly as in 12010. Even with changed size multi-byte functions just return return result like a byte array, i.e. without conversion. Since python try to validate wide character at some point will be raised exception invalid multi-byte.
Only for test work around could be implement - "fake" conversion functions that just store char into wchar array and to use ascii codec.
Next is that lack of locale support and lack of locale information(structure is without members).
Another issue is that loader does not resolve indirect dependencies. Many python modules depend from math library but are not linked with it and math functions are resolved later. This does not work on android and those modules must be explicitly linked to math library.
Also posix semaphores must be disabled.
As result python 3k regression tests except those that require locale support or ctype will pass.
mingwandroid commentedon Jun 7, 2012
Re Android
Ah of course. In that case, there's always the NDK built by Dmitry (his latest is v7 AFAIK):
http://www.crystax.net/en/android/ndk
python-dev commentedon Jun 30, 2012
New changeset 56c574a1819a by doko in branch 'default':
http://hg.python.org/cpython/rev/56c574a1819a
python-dev commentedon Jun 30, 2012
New changeset af15910d2ffb by doko in branch 'default':
http://hg.python.org/cpython/rev/af15910d2ffb
doko42 commentedon Jun 30, 2012
updated the patch in issue bpo-14330.
doko42 commentedon Jun 30, 2012
some chunks of the python-py3k-20120607-CROSS.patch patch are now checked in.
I didn't see any issues with the symlinks, and generating the posix vars, so maybe these bits should be dropped from the patch.
remaining issues are:
the readline/ncurses configury. maybe this should be done
in the configure.ac using the host tools, and then provided
to setup.py by a Makefile macro?
why are the Makefile changes for setup.info, pyconfig.h needed?
is the _testembed change still needed?
does Python/importlib.h really need a rebuild if it's there?
I think this should just fail, not removed for the cross build.
why is the ac_cv_thread vs. ac_cv_pthread change needed?
python-dev commentedon Jun 30, 2012
New changeset d158b0a78390 by doko in branch 'default':
http://hg.python.org/cpython/rev/d158b0a78390
doko42 commentedon Jun 30, 2012
for the readline ldd check, I'm checking in a patch to use readelf instead of ldd for the cross build.
python-dev commentedon Jun 30, 2012
New changeset e6e99d449bdc by doko in branch 'default':
http://hg.python.org/cpython/rev/e6e99d449bdc
doko42 commentedon Jun 30, 2012
the ncurses/_flags changes seem to be unrelated. please open a separate issue.
python-dev commentedon Jun 30, 2012
New changeset 12a56a349af2 by doko in branch 'default':
http://hg.python.org/cpython/rev/12a56a349af2
mingwandroid commentedon Jun 30, 2012
NCURSES_INTERNALS stuff appears to be redundant:
Mac OS X curses.h, Linux curses.h and Windows PDCurses.h don't reference it, nor does the Python 3.3.0b1 source code. Of course, I haven't checked any other systems.
However: see http://bugs.python.org/issue14598, so maybe for older Linux ncurses and Cygwin it is still needed.
NCURSES_OPAQUE investigation:
So for OSX we need to be defining it to 0...
but IMHO, these parts are not directly related to cross compilation support so shouldn't be part of this patch.
doko42 commentedon Jun 30, 2012
Roumen, I would like to close this issue. Please could you file separate issues for the remaining bits?
the thread/pthread configure issue
the generation of the Setup / pyconfig.h files?
rpetrov commentedon Jun 30, 2012
Matthias I cannot follow all you questions as I'm on vacation so briefly:
a) ac_cv_thread is type correct one is with'p'
b) ncurses
NCURSES_INTERNALS reported again in bpo-14598
NCURSES_OPAQUE - i don't have time to explain all details but it could be reproduces on linux with version 2.7
Even on linux to linux build it is required as it could depend from ncurses library version.
c) setup_info is my proposition to pass detection of readline libs from configure to setup.py . Use of readelf is not portable. Why to test again ? If on host platforms shared library is not in elf format which tool to use ?
d) importlib.h is build now from executable. Probably we could introduce BUILD_CC . Out of scope for now
e) executable that load packages has to be located in builddir to allow "is python build" to be activated and packages from cross-build environment to be loaded.
After 3 weeks I could answer more.
rpetrov commentedon Jul 29, 2012
I hope that following separate issues will address remaining part of this patch:
required:
optional:
and all other that allow python to be build smoothly outside source directory
eudoxos commentedon Oct 2, 2012
Being a newcomer to this issue, I would like to ask for a brief summary about which parts of the patch are checked in for 3.3.0 and which are still to be applied.
Roumen mentions bpo-15483, bpo-15484, bpo-15268 and the ac_cv_thread in the previous post as mandatory and bpo-15298 and bpo-14598 as optional; can I add those as dependencies of this issue?
python-py3k-20120607-CROSS.patch does not apply to 3.3.0 cleanly, but looking quickly at .rej files suggests that rejected hunks are those which were already merged for 3.3.0 final. Can someone confirm that?
rpetrov commentedon Oct 6, 2012
Hi Václav,
uploaded file py3k-20121004-CROSS.tgz contain current status of patch extracted as is from my repository, i.e. on small chunks. I have no idea what is in 3.3.0 .
ambrop7 commentedon Nov 5, 2012
I've applied all patches from py3k-20121004-CROSS.tgz to Python 3.3.0 except 2, 4, and 9 (which didn't apply), but it's not working. After it builds the built in modules, it tries to run the parser generator which was cross-compiled.
make Parser/pgen
make[1]: Entering directory
/root/Python-3.3.0' armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Python/dynamic_annotations.o](https://github.com/python/cpython/blob/main/Python/dynamic_annotations.o) [Python/dynamic_annotations.c](https://github.com/python/cpython/blob/main/Python/dynamic_annotations.c) armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Python/mysnprintf.o](https://github.com/python/cpython/blob/main/Python/mysnprintf.o) [Python/mysnprintf.c](https://github.com/python/cpython/blob/main/Python/mysnprintf.c) armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Python/pyctype.o](https://github.com/python/cpython/blob/main/Python/pyctype.o) [Python/pyctype.c](https://github.com/python/cpython/blob/main/Python/pyctype.c) armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Parser/tokenizer_pgen.o](https://github.com/python/cpython/blob/main/Parser/tokenizer_pgen.o) [Parser/tokenizer_pgen.c](https://github.com/python/cpython/blob/main/Parser/tokenizer_pgen.c) armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Parser/printgrammar.o](https://github.com/python/cpython/blob/main/Parser/printgrammar.o) [Parser/printgrammar.c](https://github.com/python/cpython/blob/main/Parser/printgrammar.c) armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Parser/parsetok_pgen.o](https://github.com/python/cpython/blob/main/Parser/parsetok_pgen.o) [Parser/parsetok_pgen.c](https://github.com/python/cpython/blob/main/Parser/parsetok_pgen.c) armv5tel-softfloat-linux-gnueabi-gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o [Parser/pgenmain.o](https://github.com/python/cpython/blob/main/Parser/pgenmain.o) [Parser/pgenmain.c](https://github.com/python/cpython/blob/main/Parser/pgenmain.c) armv5tel-softfloat-linux-gnueabi-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes [Parser/acceler.o](https://github.com/python/cpython/blob/main/Parser/acceler.o) [Parser/grammar1.o](https://github.com/python/cpython/blob/main/Parser/grammar1.o) [Parser/listnode.o](https://github.com/python/cpython/blob/main/Parser/listnode.o) [Parser/node.o](https://github.com/python/cpython/blob/main/Parser/node.o) [Parser/parser.o](https://github.com/python/cpython/blob/main/Parser/parser.o) [Parser/bitset.o](https://github.com/python/cpython/blob/main/Parser/bitset.o) [Parser/metagrammar.o](https://github.com/python/cpython/blob/main/Parser/metagrammar.o) [Parser/firstsets.o](https://github.com/python/cpython/blob/main/Parser/firstsets.o) [Parser/grammar.o](https://github.com/python/cpython/blob/main/Parser/grammar.o) [Parser/pgen.o](https://github.com/python/cpython/blob/main/Parser/pgen.o) [Objects/obmalloc.o](https://github.com/python/cpython/blob/main/Objects/obmalloc.o) [Python/dynamic_annotations.o](https://github.com/python/cpython/blob/main/Python/dynamic_annotations.o) [Python/mysnprintf.o](https://github.com/python/cpython/blob/main/Python/mysnprintf.o) [Python/pyctype.o](https://github.com/python/cpython/blob/main/Python/pyctype.o) [Parser/tokenizer_pgen.o](https://github.com/python/cpython/blob/main/Parser/tokenizer_pgen.o) [Parser/printgrammar.o](https://github.com/python/cpython/blob/main/Parser/printgrammar.o) [Parser/parsetok_pgen.o](https://github.com/python/cpython/blob/main/Parser/parsetok_pgen.o) [Parser/pgenmain.o](https://github.com/python/cpython/blob/main/Parser/pgenmain.o) -lpthread -ldl -lpthread -lutil -o [Parser/pgen](https://github.com/python/cpython/blob/main/Parser/pgen) make[1]: Leaving directory/root/Python-3.3.0'Parser/pgen ./Grammar/Grammar ./Include/graminit.h ./Python/graminit.c
Parser/pgen: Parser/pgen: cannot execute binary file
make: *** [Include/graminit.h] Error 126
ambrop7 commentedon Nov 5, 2012
Forgot to mention: I did run autoreconf after applying the patches. I'm attaching the full output.
ambrop7 commentedon Nov 5, 2012
A minor issue: if only --host= is specified on command line but not --build=, then cross_compiling variable is only defined after AC_PROG_CC is called. However, configure.ac uses it before that (e.g. the part at the top which looks for a python interpreter). Well, more precisely, something in autoconf sets it to cross_compiling=maybe.
rpetrov commentedon Nov 6, 2012
HI, Ambroz
Ambroz Bizjak wrote:
About patches :
2: restore graminit.* to source directory
4: restore AST to source directory
After this touch files to avoid timestamp dependencies to launch extra
build .
You issue was reported and I guess is documented . It is related to
checkout from repository and to general build process.
I have a shell script to this but in brief script touch in source tree
following files:
If you decide to build in source tree patch 2 and 4 could be skipped .
Note that listed patches allow user to keep separate builds at same time
for different platforms. As side effect part of patches could help to
build with different configuration options.
For one time cross-build users could use following scenario:
Repeat 2 & 3 for each platform
about 9: pass all top configure arguments to libffi configure to allow
users to build it properly
It is save to ignore this patch if libffi build is fine for you host
platform. Otherwise .... just change setup to use only
...
config_args = sysconfig.get_config_var("CONFIG_ARGS")
...
and replace " ".join(config_args) with config_args in command.
For instance I have build for a platform and with filtered "configure
arguments" build fail. Instead to patch libffi code I prefer from main
configure command line to control build of libffi.
Roumen
python-dev commentedon Jan 25, 2013
New changeset 11a18263ceb7 by doko in branch '2.7':
http://hg.python.org/cpython/rev/11a18263ceb7
New changeset e28b30e6eee6 by doko in branch '3.2':
http://hg.python.org/cpython/rev/e28b30e6eee6
New changeset 5464a534e7bd by doko in branch '3.3':
http://hg.python.org/cpython/rev/5464a534e7bd
New changeset ee48728e3695 by doko in branch 'default':
http://hg.python.org/cpython/rev/ee48728e3695
doko42 commentedon Jan 25, 2013
about py3k-20121004-CROSS.tgz:
committed 0001-CROSS-fix-typo-in-thread-AC_CACHE_VAL.patch
0002-CROSS-restore-graminit.-to-source-directory.patch
is this necessary? Assuming that you have correct time
stamps, this is something which usually is not built during
a cross build.
Can we just have a shell script which touches some files
so that you can cross-build even from the repository without
building pgen?
Do the release managers have such a script which is run
when building a release?
0003-CROSS-restore-importlib-header-to-source-directory-a.patch
Same as for 0002, using correct timestamps. The EXEEXT is a
different issue. However I'm not sure what to use, EXEEXT,
or BUILDEXEEXT.
0004-CROSS-restore-AST-to-source-directory.patch
Same as for 0002. Btw, does this fail with a native out-of-tree
build too?
0005-CROSS-revert-issue13150-i.e.-python-solution-with-_s.patch
A comment like "The fix for issue bpo-13150 is bogus and break
everything" might not the best way to convince maintainers ...
This works for me, and IMO should be dropped, or please explain
why this doesn't work for you.
0006-CROSS-initialise-include-and-library-paths.patch
Afaics, a similar patch is now applied. Can be dropped.
0007-CROSS-set-_PYTHON_PROJECT_BASE-to-current-build-dir.patch
Applied.
0008-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfi.patch
Applied.
0009-CROSS-pass-all-top-configure-arguments-to-libffi-con.patch
Why is it needed to pass all configure args?
0010-CROSS-warn-only-if-readelf-is-not-in-host-triplet-fo.patch
Why is this needed just for readelf? If you do have a cross
toolchain installed, then this should be available with
the triplet name, same as for gcc, as, ...
0011-CROSS-append-gcc-library-search-paths-instead-to-pre.patch
Looks ok. Could you mention where this does make a difference,
or do you just want to keep the search order as defined by
the compiler?
0012-CROSS-avoid-ncursesw-include-path-hack.patch
This would break cross-building in a multiarch environment.
Maybe we need a --with-curses-incdir=<> option.
0013-CROSS-properly-detect-WINDOW-_flags-for-different-nc.patch
This should be a separate issue. Not cross specific.
0014-CROSS-use-build-directory-as-root-for-regression-tes.patch
why is this necessary?
0015-CROSS-test-tools-has-to-depend-only-from-location-of.patch
Looks ok, but not cross specific. Could you file a separate issue?
0016-CROSS-reload-may-fail-with-operation-on-closed-file-.patch
Looks like a separate issue.
rpetrov commentedon Jan 26, 2013
Matthias Klose wrote:
All above is related to build out of source tree.
Try to keep a build tree for long time. Synchronize source, for instance
once in week, and try to rebuild. After updates in those files python
(native build) crash.
Solutions:
a) restore to source tree as before and only for cross build touch files
to avoid regeneration.
b) after synchronization copy to build tree but now in all cases.
Note that a) will allow you to build from readonly source tree .
How old is patch ? Before generated "python solution" to be moved from
source tree to
cat pybuilddir.txt. So thanks to all that resolvedesign failure with commit for bpo-13150. It seems to me author is not
able to rewrite => bpo-13547, bpo-14774, bpo-16342(?) .
Now obsolete by bpo-15298 (10x Trent).
May be I'm wrong to use cross build for multilib , i.e. with gcc -m32.
In this case does not exist prefixed readelf.
bpo-15485
My multilib compiler list fist paths to 64 libraries the to 32. 64 bit
is with all dependent libraries and headers but 32-compatible lack some
(tk/tcl for instance). As result 32 bit build find all "required"
dependency, try to link all modules and fail on missing.
Distutil library search is limited - just search for library name.
May be (bpo-15268).
bpo-14598 and bpo-15484.
For instance is source tree is readonly . It is important in cross to
avoid build defects to update source files.
Result is parallel build and test for multiple host.
Unfortunately issue is closed. It was fixed perfectly for about 2 hours.
I just revert commit.
Same as 14 rule apply.
May be is not same as bpo-15833 (fixed+closed). May be case is only for
regression test if source tree is readonly.
Roumen
rpetrov commentedon Feb 2, 2013
I agree that cross-compilation is now usable.
Issues related to build and test outside source tree more or less are permanent but out of cross-compilation scope.
Also parts of patches posted in this issue now are in separate defects or enhancements.
GregHellings commentedon Feb 5, 2013
I'm trying to cross-compile the latest default out of Mercurial based on the status of this. Currently it fails with the following invocation:
This is in a Fedora 18 environment using its included MinGW packages to do the cross compile. I have applied no patches and just did the hg clone this morning from the official repository. Are any of these attached patches still necessary? Is there any documentation about what the process is now for doing the cross-compile build?
mingwandroid commentedon Feb 5, 2013
Yes, patches are still required.
Mainly Roumen's big patch [1] and then a load more too. Matthias Klose has merged a few cross compilation patches.
Here my project with patches for 3.3.0 and an emphasis on cross:
https://github.com/mingwandroid/crucifixion-freedom
...and here's mingwbuilds with the exact same patches (but likely tidier build scripts) without the cross focus:
https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0
Next time there's a release of Python 3, I'll rebase my patches against that.
[1] http://bugs.python.org/issue3871
GregHellings commentedon Feb 5, 2013
Bummer, the patches in that issue do not apply cleanly to either the 3.3.0 released tarball nor to the 3.3 branch from hg.
doko42 commentedon Feb 6, 2013
See http://mail.python.org/pipermail/python-dev/2013-January/123774.html
for the discussion.
Not updating the patches for tip/trunk is the best way to keep them out of the project.
packge/pkg-python: drop custom environment variables