New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cross-compilation support for python build #48004
Comments
This is minimal patch that add basic cross-compilation possibilities for The patch add macro AC_CANONICAL_HOST. As result of macro new variable $host ("host triplet":=cpu-verdor-os) is Since this is basic patch, detection of build system in native builds Also the patch posted in http://bugs.python.org/issue3718 (about |
The support for *-mingw host is enhanced to native msys environment. Also check libintl is skipped for mingw as the native build don't use it. |
system python has to be at least revision 77704 (trunk) |
As part of bpo-8510 (update to autoconf2.65) configure script is modernized and most of updates from patches attached to this issue now are in repository. Starting from 16 may new patches will include in addition minimal updates of setup.py and Makefile.pre.in (moved from bpo-3871) :
|
|
Could someone with knowledge of the Python build systems please comment on this, thanks. |
It seems to me I forgot to upload version after updates in Lib/sysconfig.py from bpo-7880. This patch is restored previous behaviour and now symlinked system python into cross build tree will behave as before i.e. as expected ;) |
fixed patch failure on Parser/pgen.stamp |
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>. |
Uhh after some pseudo multiarch improvements previous patch fail. So new one is uploaded. |
Current patch errors with the following message: |
Greg, ensure correct configure script first as run commands autoheader and autoconf. |
Would it be possible to get list of steps required to test this patch?
What else? |
Usually this is not a question for bug-tracking system . configure .. Roumen |
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? |
as well, by default one experiences checking for /dev/ptmx... not set the workaround:
ac_cv_file__dev_ptmx=no
ac_cv_file__dev_ptc=no
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? |
next question. when starting compilation i am getting In file included from Include/Python.h:50, how to deal with above? |
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? |
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) ac_cv_little_endian_double=yes
ac_cv_broken_sem_getvalue=no
ac_cv_computed_gotos=yes
ac_cv_buggy_getaddrinfo=no
ac_cv_working_tzset=yes
#next line require fix typo in configure.in
ac_cv_pthread=yes
ac_cv_pthread_system_supported=yes
ac_cv_tanh_preserves_zero_sign=yes
ac_cv_have_long_long_format=yes
ac_cv_file__dev_ptmx=yes
ac_cv_file__dev_ptc=no ================================= Also with following patch into configure.in diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -1372,7 +1372,7 @@
# so we need to run a program to see whether it really made the
# function available.
AC_MSG_CHECKING(whether $CC accepts -pthread)
-AC_CACHE_VAL(ac_cv_thread,
+AC_CACHE_VAL(ac_cv_pthread,
[ac_save_cc="$CC"
CC="$CC -pthread"
AC_RUN_IFELSE([AC_LANG_SOURCE([[ ======================================= |
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. |
Roumen, do you have a newer patch which applies to the current trunk? |
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. |
Not for distutils (feature-frozen, see previous messages) |
bpo-14330 handles not using the host python for the build |
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: CC="arm-linux-gnueabihf-gcc" \
CXX="arm-linux-gnueabihf-g++" \
CFLAGS="-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security" \
LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro" \
../cross/configure \
--prefix=/usr \
--enable-ipv6 \
--with-computed-gotos \
--enable-loadable-sqlite-extensions \
--with-dbmliborder=bdb:gdbm \
--with-system-expat \
--with-system-ffi \
--with-fpectl \
--host=arm-linux-gnueabihf \
--build=x86_64-linux-gnu building 'cmath' extension the source files are not found (srcdir != builddir), the patch from rpetrov talks about: +# revert patch from bpo-7880 : but I'm running out of time, and won't work on this for the next two weeks. |
I cannot test arm build due to bpo-12010 |
updated the patch in issue bpo-14330. |
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:
|
New changeset d158b0a78390 by doko in branch 'default':
|
for the readline ldd check, I'm checking in a patch to use readelf instead of ldd for the cross build. |
New changeset e6e99d449bdc by doko in branch 'default':
|
the ncurses/_flags changes seem to be unrelated. please open a separate issue. |
New changeset 12a56a349af2 by doko in branch 'default':
|
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: Linux ncurses.h:
#ifndef NCURSES_OPAQUE
#define NCURSES_OPAQUE 0
#endif
Mac OS X ncurses.h:
#ifndef NCURSES_OPAQUE
#define NCURSES_OPAQUE 1
#endif 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. |
Roumen, I would like to close this issue. Please could you file separate issues for the remaining bits?
|
Matthias I cannot follow all you questions as I'm on vacation so briefly: 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. |
I hope that following separate issues will address remaining part of this patch: required:
optional:
|
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? |
Hi Václav, |
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 |
Forgot to mention: I did run autoreconf after applying the patches. I'm attaching the full output. |
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. |
HI, Ambroz Ambroz Bizjak wrote:
About patches : After this touch files to avoid timestamp dependencies to launch extra If you decide to build in source tree patch 2 and 4 could be skipped . For one time cross-build users could use following scenario:
about 9: pass all top configure arguments to libffi configure to allow For instance I have build for a platform and with filtered "configure Roumen |
New changeset 11a18263ceb7 by doko in branch '2.7':
New changeset e28b30e6eee6 by doko in branch '3.2':
New changeset 5464a534e7bd by doko in branch '3.3':
New changeset ee48728e3695 by doko in branch 'default':
|
about py3k-20121004-CROSS.tgz:
|
Matthias Klose wrote:
All above is related to build out of source tree.
How old is patch ? Before generated "python solution" to be moved from
May be I'm wrong to use cross build for multilib , i.e. with gcc -m32.
bpo-15485
May be (bpo-15268).
For instance is source tree is readonly . It is important in cross to
Unfortunately issue is closed. It was fixed perfectly for about 2 hours.
May be is not same as bpo-15833 (fixed+closed). May be case is only for Roumen |
I agree that cross-compilation is now usable. |
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: $ ../configure --host=i686-w64-mingw32 --build=x86_64-redhat-linux-gnu --target=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32/sys-root/mingw --exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw --bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin --sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin --sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc --datadir=/usr/i686-w64-mingw32/sys-root/mingw/share --includedir=/usr/i686-w64-mingw32/sys-root/mingw/include --libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib --libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec --localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var --sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com --mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man --infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info --enable-ipv6 --enable-shared --with-computed-gotos=yes --with-dbmliborder=gdbm:ndbm:bdb --with-system-expat --with-system-ffi --with-pydebug --with-tsc
checking for hg... found
checking build system type... x86_64-redhat-linux-gnu
checking host system type... i686-w64-mingw32
checking for python interpreter for cross build... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... configure: error: cross build not supported for i686-w64-mingw32
error: Bad exit status from /var/tmp/rpm-tmp.sZjjCl (%build) 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? |
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: ...and here's mingwbuilds with the exact same patches (but likely tidier build scripts) without the cross focus: Next time there's a release of Python 3, I'll rebase my patches against that. |
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. |
See http://mail.python.org/pipermail/python-dev/2013-January/123774.html Not updating the patches for tip/trunk is the best way to keep them out of the project. |
Many moons ago, in the dark ages of Python, cross compiles were largely unsupported. In these before-times, a patchset used by PtxDist [0] [1] was adapted to help make cross compiles work. The patchset did a number of things but mainly: 1) used a build-machine compatible python interpreter for certain stages of the target Python build process 2) made adjustments to certain files to make decisions based on values set in environment variables instead of the path of the executing Python interpreter. Since the path of the interpreter that was build machine compatible was outside of the target build directory, the code that made assumptions about the location of headers and library paths being relative to the interpreter path needed to be adjusted, hence them being driven via environment variables. The patchset worked by replacing the executable path to be the sysroot which included the python headers and libraries. A number of issues regarding cross compilation [2] [3] [4] have since been closed since the introduction of this patchset and cross builds became much better supported starting in Python v3.3.1. New logic primarily uses the _PYTHON_PROJECT_BASE env variable [5] [6]. When set properly, this drives a few things: * flags a cross compile environment * sysconfig.is_python_build = True which triggers: * altered paths for finding the Makefile and config.h * altered sysconfig.get_config_var("srcdir") When migrating to Python 3.4, PtxDist reworked their patchset to use the standard environment variables for their cross compiles [7]. The distutils module was a primary consumer of the custom variables from the previous patchset, however, that module is deprecated and packages cannot target it as of 09de823. Package builds and unit tests seem to work without using these variables being set, implying they can likely be dropped. Packages that still use distutils should be updated to reflect its removal in 3.12. Once these custom variables are removed, the following Python3 patches which leverage them can be dropped: 0004-Adjust-library-header-paths-for-cross-compilation 0009-Do-not-adjust-the-shebang-of-Python-scripts-for-cros [0]: https://gitlab.vahanus.net/ptxdist/ptxdist/-/commit/eef994411c20653cde95b35266000e3a8754e3b3 [1]: https://gitlab.vahanus.net/ptxdist/ptxdist/-/commit/6c79cb5ac373b1cccf531e8be3ed1b9722ed1622 [2]: python/cpython#48004 [3]: python/cpython#58538 [4]: python/cpython#59689 [5]: python/cpython@7e6c2e2 [6]: python/cpython@9731330 [7]: https://gitlab.vahanus.net/ptxdist/ptxdist/-/commit/638a024500c214c1d8283bce8cec864fb95deacf Signed-off-by: Vincent Fazio <vfazio@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: