search

python / cpython

The Python programming language
https://www.python.org/
Other
60.03k stars 29.06k forks source link

cross-compilation support for python build #48004

Closed d8d5aad8-e55b-4500-a3a0-9ea982d771ff closed 11 years ago

d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 15 years ago
BPO 3754
Nosy @doko42, @vapier, @tarekziade, @merwok, @mingwandroid
Files
  • python-trunk-20100516-CROSS.patch
  • python-trunk-20100626-CROSS.patch
  • python-trunk-20100824-CROSS.patch
  • python-2.7-20101112-CROSS.patch
  • python-py3k-20101112-CROSS.patch
  • python-2.7-20110126-CROSS.patch
  • python-py3k-20110126-CROSS.patch
  • python-py3k-20110407-CROSS.patch
  • python-py3k-20110520-CROSS.patch
  • python-py3k-20110825-CROSS.patch
  • python-py3k-20120318-CROSS.patch
  • python-py3k-20120318-CROSS-330a2.patch: Patch updated to build against 3.3.0a2
  • python-py3k-20120607-CROSS.patch: version for 3.3.0a4
  • py3k-20121004-CROSS.tgz
  • log
    		•

    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: ```python assignee = 'https://github.com/tarekziade' closed_at = created_at = labels = ['type-feature', 'build'] title = 'cross-compilation support for python build' updated_at = user = 'https://bugs.python.org/rpetrov' ``` bugs.python.org fields: ```python activity = actor = 'doko' assignee = 'tarek' closed = True closed_date = closer = 'rpetrov' components = ['Cross-Build'] creation = 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'] ```

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 15 years ago

    This is minimal patch that add basic cross-compilation possibilities for python build (configure script).

    The patch add macro AC_CANONICAL_HOST. This macro require files config.guess, config.sub. The patch don't include them. You may obtain them from GNU automake tarbal.

    As result of macro new variable $host ("host triplet":=cpu-verdor-os) is used to detect so called "host system".

    Since this is basic patch, detection of build system in native builds based on $ac_sys_system and/or $ac_sys_release isn't replaced. This detection isn't appropriate for cross-compilation environment as contain values for "build system" and has to be replaces in addition by future patches.

    Also the patch posted in http://bugs.python.org/issue3718 (about environment variable MACHDEP) isn't required for native builds, but will help in case of cross-compilation.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 15 years ago

    The support for *-mingw host is enhanced to native msys environment. This include check for device file /dev/ptmx. The MSYS report that file exist. As the check is skipped on mingw* host os now cugwin environment can be used too.

    Also check libintl is skipped for mingw as the native build don't use it.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 14 years ago

    system python has to be at least revision 77704 (trunk)

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 14 years ago

    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) :

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 13 years ago
    83d2e70e-e599-4a04-b820-3814bbdb9bef commented 13 years ago

    Could someone with knowledge of the Python build systems please comment on this, thanks.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 13 years ago

    It seems to me I forgot to upload version after updates in Lib/sysconfig.py from bpo-7880. I could not understand what Florent Xicluna (flox). I could not reproduce it. To me update abspath -> realpath is bogus and with reverted update of Lib/sysconfig.py test_sysconfig pass.

    This patch is restored previous behaviour and now symlinked system python into cross build tree will behave as before i.e. as expected ;)

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 13 years ago

    fixed patch failure on Parser/pgen.stamp

    merwok commented 13 years ago

    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>.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 13 years ago

    Uhh after some pseudo multiarch improvements previous patch fail. So new one is uploaded. Also with this version cross-build won't build pgen$(EXEEXT).

    c265ad65-a17a-442b-995d-152a2551e665 commented 13 years ago

    Current patch errors with the following message: gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -L/manual/lib -L/binary/lib -L/manual/lib -L/binary/lib Parser/acceler.o Parser/grammar1.o Pars er/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain .o -lintl -lpthread -o Parser/pgen.exe ./Grammar/Grammar ./Include/graminit.h ./Python/graminit.c ./Grammar/Grammar: line 18: single_input:: command not found ./Grammar/Grammar: line 18: simple_stmt: command not found ./Grammar/Grammar: line 18: compound_stmt: command not found ./Grammar/Grammar: line 19: syntax error near unexpected token NEWLINE' ./Grammar/Grammar: line 19:file_input: (NEWLINE | stmt)* ENDMARKER' make: *** [Parser/pgen.stamp] Error 2

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 12 years ago

    Greg, ensure correct configure script first as run commands autoheader and autoconf. Updates to configure script are not in patch . The patch include updates to source configure.in and autoconf command will update "configure".

    1b5f39fd-febf-4146-81ba-6d85f5f45122 commented 12 years ago

    Would it be possible to get list of steps required to test this patch?

    1. hg clone
    2. copy config.sub and config.guess?
    3. autoreconf
    4. configure...
    5. make

    What else?

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 12 years ago

    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

    1b5f39fd-febf-4146-81ba-6d85f5f45122 commented 12 years ago

    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?

    1b5f39fd-febf-4146-81ba-6d85f5f45122 commented 12 years ago

    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:

    1. create config.site file with the following lines
         ac_cv_file__dev_ptmx=no
     ac_cv_file__dev_ptc=no
    1. run configure script as: CONFIG_SITE=config.site ./configure --host...

    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?

    1b5f39fd-febf-4146-81ba-6d85f5f45122 commented 12 years ago

    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?

    1b5f39fd-febf-4146-81ba-6d85f5f45122 commented 12 years ago

    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

    1. if in cross compilation mode, the configure.in could load config-cross.site.
    2. the config-cross.site would define variables for ptmx/ptc, long long format and other checks which consist of running code snippets
    3. appropriate checks (i.e. ptmx/ptc, lld/llu) would not be run in cross compilation mode. variables from config-cross.site would be used instead.
    4. it would be a developer responsibility to set appropriate values for his platform in config-cross.site file.

    does above sound like a solution?

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 12 years ago

    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([[

    =======================================

    merwok commented 12 years ago

    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 commented 12 years ago

    Roumen, do you have a newer patch which applies to the current trunk?

    doko42 commented 12 years ago

    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 commented 12 years ago

    Not for distutils (feature-frozen, see previous messages)

    doko42 commented 12 years ago

    bpo-14330 handles not using the host python for the build

    doko42 commented 12 years ago

    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 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.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 12 years ago

    I cannot test arm build due to bpo-12010

    e922ebb1-1640-4416-a8e2-e01fc644b797 commented 11 years ago

    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:

    test.c:
#include <stdlib.h>
char bytes[(signed)sizeof(wchar_t)-4];

    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.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 11 years ago

    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.

    e922ebb1-1640-4416-a8e2-e01fc644b797 commented 11 years ago

    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

    1762cc99-3127-4a62-9baf-30c3d0f51ef7 commented 11 years ago

    New changeset 56c574a1819a by doko in branch 'default':

    1762cc99-3127-4a62-9baf-30c3d0f51ef7 commented 11 years ago

    New changeset af15910d2ffb by doko in branch 'default':

    doko42 commented 11 years ago

    updated the patch in issue bpo-14330.

    doko42 commented 11 years ago

    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:

    1762cc99-3127-4a62-9baf-30c3d0f51ef7 commented 11 years ago

    New changeset d158b0a78390 by doko in branch 'default':

    doko42 commented 11 years ago

    for the readline ldd check, I'm checking in a patch to use readelf instead of ldd for the cross build.

    1762cc99-3127-4a62-9baf-30c3d0f51ef7 commented 11 years ago

    New changeset e6e99d449bdc by doko in branch 'default':

    doko42 commented 11 years ago

    the ncurses/_flags changes seem to be unrelated. please open a separate issue.

    1762cc99-3127-4a62-9baf-30c3d0f51ef7 commented 11 years ago

    New changeset 12a56a349af2 by doko in branch 'default':

    e922ebb1-1640-4416-a8e2-e01fc644b797 commented 11 years ago

    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.

    doko42 commented 11 years ago

    Roumen, I would like to close this issue. Please could you file separate issues for the remaining bits?

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 11 years ago

    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.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 11 years ago

    I hope that following separate issues will address remaining part of this patch:

    required:

    optional:

    2a7ae423-2b47-43d7-8028-1536a8dd620c commented 11 years ago

    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?

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 11 years ago

    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 .

    8f4018d2-0106-4539-b846-f5fe4cdf441c commented 11 years ago

    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

    8f4018d2-0106-4539-b846-f5fe4cdf441c commented 11 years ago

    Forgot to mention: I did run autoreconf after applying the patches. I'm attaching the full output.

    8f4018d2-0106-4539-b846-f5fe4cdf441c commented 11 years ago

    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.

    d8d5aad8-e55b-4500-a3a0-9ea982d771ff commented 11 years ago

    HI, Ambroz

    Ambroz Bizjak wrote:

    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. 3.3.0 was split from head long time before release and I did not spend time to check what is actually entered.

    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: 1) native configuration, build and installation 2) clean source tree 3) cross build&pack for one platform. 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

    1762cc99-3127-4a62-9baf-30c3d0f51ef7 commented 11 years ago

    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':

    doko42 commented 11 years ago

    about py3k-20121004-CROSS.tgz: