[issue28833] cross compilation of third-party extension modules

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

[issue28833] cross compilation of third-party extension modules

Xavier de Gaye added the comment: PR 17420 fixes cross-compilation of third-party extension modules. The PYTHON_PROJECT_BASE environment variable is the path to the directory where Python has been cross-compiled. It is used by the native python interpreter to find the target sysconfigdata

[issue28833] cross compilation of third-party extension modules

Change by Xavier de Gaye : -- pull_requests: +16901 pull_request: https://github.com/python/cpython/pull/17420 ___ Python tracker ___

[issue28833] cross compilation of third-party extension modules

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

[issue28833] cross compilation of third-party extension modules

Changes by Xavier de Gaye : -- assignee: xdegaye -> ___ Python tracker ___ ___

[issue28833] cross compilation of third-party extension modules

Matthias Klose added the comment: > Hum, you still need to provide the native python interpreter > with the _path_ to the -python-config executable that > can be anywhere on the file system No, it's found in the same path. No contradiction. > So I suggest we start with this patch as it works

[issue28833] cross compilation of third-party extension modules

Matthias Klose added the comment: again, I don't think relying on a specific target path for a cross target is a good idea. and now deciding that the last possibility to use a target id to identify is better is internal doesn't make it better. I'd appreciate if we could sit together where

[issue28833] cross compilation of third-party extension modules

Chi Hsuan Yen added the comment: I know. I guess it can be determined without manually specifying but haven't investigated into details. Maybe some patches are necessary. -- ___ Python tracker

[issue28833] cross compilation of third-party extension modules

Xavier de Gaye added the comment: $ _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_aarch64-linux-android PYTHONHOME=~/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr python3.7 setup.py build_ext > Variables prefixed by an underscore such as '_PYTHON_SYSCONFIGDATA_NAME' are

[issue28833] cross compilation of third-party extension modules

Chi Hsuan Yen added the comment: Well, cross compiling extension modules already works fine... $ _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_aarch64-linux-android PYTHONHOME=~/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr python3.7 setup.py build_ext running build_ext

[issue28833] cross compilation of third-party extension modules

Xavier de Gaye added the comment: So I suggest we start with this patch as it works for: * The standard library extension modules (for debian as well). * The third-party extension modules on platforms that have multiarch defined and on platforms that do not have multiarch defined (on debian

[issue28833] cross compilation of third-party extension modules

Xavier de Gaye added the comment: > I don't think that identifying the target by some path is the right way to > go, and you should be able to identify the target by giving the target > triplet as used by the configure parameters and then deduce the location from > the target (or have an

[issue28833] cross compilation of third-party extension modules

Changes by Xavier de Gaye : -- nosy: +Chi Hsuan Yen ___ Python tracker ___ ___

[issue28833] cross compilation of third-party extension modules

Xavier de Gaye added the comment: > This approach will not work with a "multiarch" enabled environment, and break > cross builds on Debian and Ubuntu. No, the patch does not break cross builds on Debian and Ubuntu, unless you can demonstrate it does. > Afaics, the proposal assumes that the

[issue28833] cross compilation of third-party extension modules

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue28833] cross compilation of third-party extension modules

Matthias Klose added the comment: > * The sysconfigdata file name was terminated with a dangling > underscore when 'multiarch' is not defined. That only solves part of the problem in that the kernel/os version gets encoded as well, e.g. gnukfreebsd9, gnukfreebsd10, which is nasty when the

[issue28833] cross compilation of third-party extension modules

Matthias Klose added the comment: This approach will not work with a "multiarch" enabled environment, and break cross builds on Debian and Ubuntu. Afaics, the proposal assumes that the python executable for the target architecture is installed (which it is not for the multiarch cross-build

[issue28833] cross compilation of third-party extension modules

New submission from Xavier de Gaye: With this patch, cross compiling a third-party extension module is done with the command: XBUILD_PYTHON_DIR=/path/to/python/dir python setup.py build where XBUILD_PYTHON_DIR is the location of the directory of the cross-compiled python executable. It may