[issue433537] better cross-compilation support

Change by admin : -- github: None -> 34635 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46749] Support cross compilation on macOS

Change by Ned Deily : -- components: +macOS -Cross-Build nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46749] Support cross compilation on macOS

Ned Deily added the comment: We don't currently support cross-building a single macOS architecture on another, i.e. building an x86_64 only build on an Apple Silicon Mac. However, we do support building a multi-architecture build on either on current releases of Python 3.9 and 3.10, with

[issue46749] Support cross compilation on macOS

Change by autoantwort : -- components: +Cross-Build -Build nosy: +Alex.Willmer ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46749] Support cross compilation on macOS

not supported for x86_64-apple-darwin ``` Is "needed" for https://github.com/microsoft/vcpkg/issues/22603 -- components: Build messages: 413224 nosy: autoantwort priority: normal severity: normal status: open title: Support cross compilation on macOS type: enhancement versio

[issue44245] Cross-compilation of CPython 3.8 with _socket module using Anddroid NDK fails

Ladislav Heller added the comment: Tried to cross-compile with an old version of Android NDK. Using the latest NDK it works perfectly. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue45940] add_multiarch_paths breaks cross compilation to Emscripten

Ethan Smith added the comment: Unfortunately, I am using latest master :/ I was able to reproduce this issue in your wasm docker container mounting CPython master into it, if you want to play with this. -- ___ Python tracker

[issue45940] add_multiarch_paths breaks cross compilation to Emscripten

Christian Heimes added the comment: rm config.cache? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45940] add_multiarch_paths breaks cross compilation to Emscripten

Ethan Smith added the comment: Bah, it actually seems the real issue is that my configure is choosing the host_cpu as x86-64 for some reason. I'm still trying to figure out why though. -- ___ Python tracker

[issue45940] add_multiarch_paths breaks cross compilation to Emscripten

Christian Heimes added the comment: Could you please try again with latest master? GH-29752 should have fixed the issue. -- stage: patch review -> ___ Python tracker ___

[issue45940] add_multiarch_paths breaks cross compilation to Emscripten

Change by Ethan Smith : -- keywords: +patch pull_requests: +28094 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29868 ___ Python tracker ___

[issue45940] add_multiarch_paths breaks cross compilation to Emscripten

d. I have a patch which fixes this that I will be submitting shortly to Github. -- components: Build messages: 407387 nosy: christian.heimes, ethan smith priority: normal severity: normal status: open title: add_multiarch_paths breaks cross compilation to Emscripten type: compile erro

[issue16235] Add python-config.sh for use during cross compilation.

Change by Éric Araujo : -- Removed message: https://bugs.python.org/msg405026 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue16235] Add python-config.sh for use during cross compilation.

surbhi nahta added the comment: Hi, I am also having the same issue and found the best answer on the below site - https://python-9.jimdosite.com/ -- nosy: +nahtasurbhi123 ___ Python tracker

[issue44245] Cross-compilation of CPython 3.8 with _socket module using Anddroid NDK fails

Default, ni[i].if_name); ^ Without _socket module, the cross-compilation works well. Also the result python3 build transferred to my Android device and tested in Terminal app works well. However without _socket module for example th

[issue22699] cross-compilation of Python3.4

Steve Dower added the comment: I'm now hitting this too, on nearly all the compiled modules in the stdlib. One example: building '_codecs_jp' extension x86_64-my-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/opt/my-generic/0.0.1-dev/sysroots/core2-64-my-linux -fPIC

[issue39399] Cross compilation using different libc is broken

Andrew Aladjev added the comment: Hello, it seems like issue 22724 is completely the same. Let's discuss solutions there. Thank you. -- ___ Python tracker ___

[issue39399] Cross compilation using different libc is broken

Ned Deily added the comment: Thanks for the report. This appears to be a duplicate of languishing Issue22724. Suggest you join the discussion there. -- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> byte-compile fails for

[issue39399] Cross compilation using different libc is broken

New submission from Andrew Aladjev : Hello. I am implementing python cross compilation using "x86_64-pc-linux-musl" toolchain: "x86_64-pc-linux-musl-emerge -v1 python:3.6". Please see the following build log https://gist.github.com/andrew-aladev/e10fa5a8151ffb3c5782edd64

[issue28542] document cross compilation

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

[issue36145] android arm cross compilation fails, config issue

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

[issue36141] configure: error: could not find pthreads on your system during cross compilation

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

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

[issue23670] Modifications to support iOS as a cross-compilation target

Change by Josh Rosenberg : -- title: Restore -> Modifications to support iOS as a cross-compilation target ___ Python tracker <https://bugs.python.org/issu

[issue22699] cross-compilation of Python3.4

Sam added the comment: Has there been any update on this? I've run into this issue trying to cross-compile python for Android. I've tried 3.7.4, 3.8 and current master, both in-source and out of source builds, all ending with the modules failing to compile due to wrong paths. ...

[issue36145] android arm cross compilation fails, config issue

Xavier de Gaye added the comment: Obviously because you do not tell clang where to find those headers. -- ___ Python tracker ___

[issue36145] android arm cross compilation fails, config issue

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36145] android arm cross compilation fails, config issue

muhzi added the comment: Yes, pretty much so, which I think was what caused the pthread problem. Why would it fail to find the headers? -- ___ Python tracker ___

[issue36145] android arm cross compilation fails, config issue

Change by Xavier de Gaye : -- stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36145] android arm cross compilation fails, config issue

Xavier de Gaye added the comment: There is a bug in the implementation of pymonotonic() in Python/pytime.c: The call to pytime_fromtimespec() is not encapsulated by an #ifdef HAVE_CLOCK_GETTIME. @muhzi It seems that your pyconfig.h is generated with configure failing to find the NDK

[issue36145] android arm cross compilation fails, config issue

Change by muhzi : -- title: android arm cross compilation fails, h -> android arm cross compilation fails, config issue ___ Python tracker <https://bugs.python.org/issu

[issue36145] android arm cross compilation fails, h

tached). -- components: Cross-Build files: pyconfig.h messages: 336828 nosy: Alex.Willmer, muhzi, xdegaye priority: normal severity: normal status: open title: android arm cross compilation fails, h type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file48178/pyco

[issue36141] configure: error: could not find pthreads on your system during cross compilation

Xavier de Gaye added the comment: This is a different problem. Please create a new issue and attach pyconfig.h. -- ___ Python tracker ___

[issue36141] configure: error: could not find pthreads on your system during cross compilation

muhzi added the comment: OK! NDK version is 19.1.5304403 Cool, so I uploaded the output of configure (attachments) Sorry for the confusion about pyconfig.h, what I was trying to say is after providing ac_cv_pthread_is_default=yes to configure I get errors in make: Python/pytime.c:911:9:

[issue36141] configure: error: could not find pthreads on your system during cross compilation

Xavier de Gaye added the comment: > The problem extends after the configuration. It's as if the android headers > are not visible to configure. All the macros are undefined in the pyconfig > file too btw. pyconfig.h is generated by configure from pyconfig.h.in. Please attach the new output

[issue36141] configure: error: could not find pthreads on your system during cross compilation

muhzi added the comment: Well, it solves the problem with the configure script. My pyconfig.h.in contains: /* Define to 1 if you have the header file. */ #undef HAVE_PTHREAD_H /* Define to 1 if you have the `pthread_init' function. */ #undef HAVE_PTHREAD_INIT /* Define to 1 if you have

[issue36141] configure: error: could not find pthreads on your system during cross compilation

Xavier de Gaye added the comment: What is the NDK version ? There is no Android pthread library. It is possible that the failure comes from the fact that the first configure test on pthread_create links with pthread and that the Android linker fails now instead of ignoring this error as it

[issue36141] configure: error: could not find pthreads on your system during cross compilation

Change by muhzi : -- type: -> compile error ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36141] configure: error: could not find pthreads on your system during cross compilation

Change by muhzi : -- components: +Cross-Build nosy: +Alex.Willmer ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36141] configure: error: could not find pthreads on your system during cross compilation

-- messages: 336779 nosy: muhzi, xdegaye priority: normal severity: normal status: open title: configure: error: could not find pthreads on your system during cross compilation versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by Erik Janssens : -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: I'm sorry about that. I won't merge PR like that next time. -- ___ Python tracker ___ ___

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: As someone who has written MSDN samples, I'll spoil the secret and let you know that there's no consistency there, so you can find examples to prove either direction ;) I wasn't expecting expertise or research. I was only expecting a description of the change

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: I'll try to be more precise : - I did an (imperfect) search : before these changes 98% of the windows headers were included in the .c files in lowercase - These changes would bring it to 100% - The advantage of these changes are consistency and the ability

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: I googled and checked what MSDN uses before I merged these PRs. For example: https://msdn.microsoft.com/ja-jp/library/bb394814.aspx -- ___ Python tracker

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: > The current situation is that 100% of the windows includes are lowercase and > allow cross compilation. Please be precise with what you are saying - the "current situation" is only so because you proposed changes and got them merged without p

[issue34217] windows: cross compilation fails due to headers with uppercase

% of the windows includes are lowercase and allow cross compilation. I would tend to see that as an advantage. If a more comprehensive solution would be available, that would be ideal of course. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: Have you posted to their mailing list to ask why they use different casing from the official SDK and whether they would consider supporting both (via symlink, presumably)? I think it would be strange for CPython to add a style rule for a non-supported

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: The lowercase headers are indeed part of the mingw-w64 SDK, which is the most convenient option to cross compile on a linux host for a windows target. -- ___ Python tracker

[issue34217] windows: cross compilation fails due to headers with uppercase

Eryk Sun added the comment: > New windows will support case sensitive filesystem too. NTFS in Windows 10 supports a flag to mark a directory as case sensitive [*] via NtSetInformationFile: FileCaseSensitiveInformation, which can be set from the command line via fsutil.exe. In recent builds

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: > whatever might be the 'right' solution, it's always an advantage to > have a consistent codebase. Not when you are consistently wrong, it's not. Let's figure out the right answer here before making many changes to the codebase. First, can you tell me where

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: > Stop relying to case insensitive filesystem makes sense to me. If this is the case, then we need to normalise the casing to match the actual files (which are mixed-case, not lowercase). You just broke this with your PR :) So which is it? Do we match the

[issue34217] windows: cross compilation fails due to headers with uppercase

miss-islington added the comment: New changeset bf8e9d18dd75f58ce3b9761763ae10c0800b43d8 by Miss Islington (bot) in branch '3.7': bpo-34217: Use lowercase for windows headers (GH-8472) https://github.com/python/cpython/commit/bf8e9d18dd75f58ce3b9761763ae10c0800b43d8 --

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: New windows will support case sensitive filesystem too. Stop relying to case insensitive filesystem makes sense to me. -- ___ Python tracker

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: @inada.naoki : thank you ! @steve.dower : I would not consider those bugs per se, but they are inconsistencies, for example in the master branch : number of "Windows.h" includes : 2 number of "windows.h" includes : 55 whatever might be the 'right' solution,

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by miss-islington : -- pull_requests: +8255 stage: resolved -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: New changeset e6a4755e6793942b950c1595e0c34bd66a0ee13e by INADA Naoki (Erik Janssens) in branch 'master': bpo-34217: Use lowercase for windows headers (GH-8472) https://github.com/python/cpython/commit/e6a4755e6793942b950c1595e0c34bd66a0ee13e --

[issue34217] windows: cross compilation fails due to headers with uppercase

Steve Dower added the comment: Are those bugs? On Windows, they are spelled with that casing (and while NTFS is case-insensitive, it *is* case-preserving). Whatever package you have used for cross-compiling may have renamed them (similarly Shlwapi.h). In which case, perhaps you could

[issue34217] windows: cross compilation fails due to headers with uppercase

Erik Janssens added the comment: Attached a small helper script to detect camelcase windows headers, 2 more occurences found : Modules/socketmodule.c versionhelpers.h 306 #include Tools/msi/bundle/bootstrap/pch.h uxtheme.h 18 #include -- status: closed -> open Added file:

[issue34217] windows: cross compilation fails due to headers with uppercase

miss-islington added the comment: New changeset 6c89a9a4c7d1804e16038f9ee3a0b2efaa4bdee6 by Miss Islington (bot) in branch '3.7': bpo-34217: Use lowercase header for Windows (GH-8453) https://github.com/python/cpython/commit/6c89a9a4c7d1804e16038f9ee3a0b2efaa4bdee6 -- nosy:

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by miss-islington : -- pull_requests: +8074 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by Erik Janssens : -- pull_requests: +8058 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by INADA Naoki : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue34217] windows: cross compilation fails due to headers with uppercase

INADA Naoki added the comment: New changeset 6cf8255912c36fec6f87f62513034d0818f61390 by INADA Naoki (erikjanss) in branch 'master': bpo-34217: Use lowercase header for Windows (GH-8453) https://github.com/python/cpython/commit/6cf8255912c36fec6f87f62513034d0818f61390 -- nosy:

[issue34217] windows: cross compilation fails due to headers with uppercase

Change by Erik Janssens : -- keywords: +patch pull_requests: +7978 stage: -> patch review ___ Python tracker ___ ___

[issue34217] windows: cross compilation fails due to headers with uppercase

, erikjanss, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: windows: cross compilation fails due to headers with uppercase type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.

[issue33938] Cross compilation fail for ARM

David added the comment: After using --with-system-ffi and setting the correct LD_LIBRARY_PATH, it worked. Many thanks for the help! -- stage: -> resolved status: open -> closed ___ Python tracker

[issue33938] Cross compilation fail for ARM

pmpp added the comment: Hi, in the log i see : checking for --with-system-ffi... no if you are sure your target ffi is ok then that could look a lot like what i had for python3 cross compile to armv7 android with a self built toolchain too : https://bugs.python.org/issue31710. iirc forcing

[issue33938] Cross compilation fail for ARM

get rid of the wrong compiler flags -m64 and -mtune=generic. Target python build log attached. -- components: Cross-Build files: targetpython_build.log messages: 320222 nosy: Alex.Willmer, n0s69z priority: normal severity: normal status: open title: Cross compilation fail for ARM type: compi

[issue28538] _socket module cross-compilation error on android-24

Change by Xavier de Gaye : -- resolution: not a bug -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue28538] _socket module cross-compilation error on android-24

Xavier de Gaye added the comment: New changeset 5ad7ef8e420de8a54fb30ed37362194c6b96012c by xdegaye in branch 'master': bpo-28538: Revert all the changes (now using Android Unified Headers) (GH-4479)

[issue28538] _socket module cross-compilation error on android-24

Xavier de Gaye added the comment: These changes are not needed anymore now that Unified Headers are supported by android-ndk-r14 (see issue 29040) -- resolution: fixed -> not a bug stage: resolved -> patch review status: closed -> open

[issue28538] _socket module cross-compilation error on android-24

Change by Xavier de Gaye : -- pull_requests: +4416 ___ Python tracker ___ ___

[issue23670] Modifications to support iOS as a cross-compilation target

Russell Keith-Magee added the comment: For those interested, I've started tracking these patches on Github: https://github.com/freakboy3742/cpython The 3.4, 3.5 and 3.6 branches are tested and compile as of the time of this comment; the master branch has also been

[issue28538] _socket module cross-compilation error on android-24

Changes by Donald Stufft : -- pull_requests: +872 ___ Python tracker ___ ___

[issue23670] Modifications to support iOS as a cross-compilation target

Changes by Mariatta Wijaya : -- nosy: +Mariatta ___ Python tracker ___ ___

[issue28833] cross compilation of third-party extension modules

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

[issue23670] Modifications to support iOS as a cross-compilation target

Todd Rovito added the comment: Russell, this is excellent work I am truly amazed that within a couple of hours I had Python built and running for the iOS simulator this is a feat I didn't think was possible. Perspective on me I am very familiar with Linux, C, and Python but know very

[issue28538] _socket module cross-compilation error on android-24

Changes by Xavier de Gaye : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue28538] _socket module cross-compilation error on android-24

Roundup Robot added the comment: New changeset f34dac552ad8 by Xavier de Gaye in branch '3.6': Issue #28538: On Darwin net/if.h requires that sys/socket.h be included beforehand. https://hg.python.org/cpython/rev/f34dac552ad8 New changeset c568b6ac5e89 by Xavier de Gaye in branch 'default':

[issue28538] _socket module cross-compilation error on android-24

Xavier de Gaye added the comment: These changes break the darwin platform, socket.if_nameindex() is not defined anymore. On Darwin, 'net/if.h' requires that 'sys/socket.h' be included beforehand (see the autoconf documentation). -- ___ Python

[issue28538] _socket module cross-compilation error on android-24

Roundup Robot added the comment: New changeset e248bfb0f520 by Xavier de Gaye in branch '3.6': Issue #28538: Fix the compilation error that occurs because if_nameindex() is https://hg.python.org/cpython/rev/e248bfb0f520 New changeset 55bf0b79ec55 by Xavier de Gaye in branch 'default': Issue

[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

be: a) The build tree, which is the source tree when the cross compilation is not out of the source tree. b) '$DESTDIR/$exec_prefix/bin' when the cross built python has been installed with 'make DESTDIR=/some/path install'. In that case 'prefix' and 'exec_prefix' may be different. c) When

[issue28538] _socket module cross-compilation error on android-24

Xavier de Gaye added the comment: Patch attached. -- components: +Cross-Build keywords: +patch nosy: +Alex.Willmer, doko stage: needs patch -> patch review Added file: http://bugs.python.org/file45394/if_nameindex.patch ___ Python tracker

[issue28542] document cross compilation

Xavier de Gaye added the comment: Yes, I was not aware of DESTDIR. The 2.7 README contains also useful information on the build process, for example about some use cases of the '*shared*' entries in the Setup files (for when setup.py cannot detect/build an extension module) or about the

  1   2   3   4   >