[issue36125] Cannot cross-compile to more featureful but same tune

Change by pmp-p : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36125] Cannot cross-compile to more featureful but same tune

Change by Xavier de Gaye : -- nosy: -xdegaye ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36125] Cannot cross-compile to more featureful but same tune

Xavier de Gaye added the comment: Re-opening and setting the stage as 'needs patch': at least the cross-compilation should fail with a clear message when the cross-built libraries names and those of the native interpreter have the same suffix. > Assuming that you can rely on the loader to

[issue36125] Cannot cross-compile to more featureful but same tune

Ross Burton added the comment: That's exactly the glitch. I'm cross-compiling to a more powerful IA process from IA. This *is* a cross-compilation but the triple is the same. Assuming that you can rely on the loader to not open target binaries when they're on the path to load from is

[issue36125] Cannot cross-compile to more featureful but same tune

Xavier de Gaye added the comment: The cross-compilation rely on the fact that the cross-compiled shared libraries names are constructed using the configure `--host=HOST-TYPE' command line parameter and therefore cannot be loaded by the native compiler that uses a different suffix for those

[issue36125] Cannot cross-compile to more featureful but same tune

Ross Burton added the comment: strace disagrees. By putting strace in PYTHON_FOR_BUILD and then invoking make sharedmods: | openat(AT_FDCWD, "/data/poky-tmp/master/work/corei7-64-poky-linux/python3/3.7.2-r0/build/build/lib.linux-x86_64-3.7/_heapq.cpython-37m-x86_64-linux-gnu.so",

[issue36125] Cannot cross-compile to more featureful but same tune

Xavier de Gaye added the comment: @Ross > The intention appears to be that the sysconfig.py in the build is used. In > my case that directory is also full of shared libraries that Python happily > loads, and then fails. No, the intention is that the native python finds the sysconfigdata

[issue36125] Cannot cross-compile to more featureful but same tune

Ned Deily added the comment: Thanks for the report. Unfortunately, as far as I know, we don't claim anywhere to support cross-compiling in general. As you've probably noticed, the Python Makefile-based build system (for non-Windows platforms) is by no means a conventional GNU autotools

[issue36125] Cannot cross-compile to more featureful but same tune

Ross Burton added the comment: >From what I can tell: configure.ac sets PYTHON_FOR_BUILD like this if cross-compiling: PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo

[issue36125] Cannot cross-compile to more featureful but same tune

New submission from Ross Burton : My build machine is a Haswell Intel x86-64. I'm cross-compiling to x86-64, with -mtune=Skylake -avx2. During make install PYTHON_FOR_BUILD loads modules from the *build* Lib/ which contain instructions my Haswell can't execute: |