A Google search on "andoid x86_64" gives about 10,900,000 results, showing that cross-compiling is quite common for the case where the build system and the host system have the same PLATFORM_TRIPLET as when building android x86_64 on an x86_64. So the argument that this problem is not worth fixing because no one has to cross-compile in this environment, IMHO this argument is not valid.
Victor Stinner wrote: > https://github.com/python/cpython/issues/66913 doesn't explain how to reproduce the issue, it only gives some info about what doesn't work. > I don't know how to reproduce the issue. Yes this issue does explain how to reproduce the problem. It even shows the backtrace printed when attempting to cross-build Android x86_64 on a linux x86_64. To reproduce the issue, just cross-build python for android x86_64 following the well documented process by the Android team. It is not clear how this backtrace can be missed when reading the issue ! There is also a patch provided in this issue that is straightforward and that does not involve any change on distutils, only the Makefile and configure. Dave wrote: > Xavier de Gaye reworked the build system, apparently fixing the problem with this pull request in Dec. 2019: https://github.com/python/cpython/pull/17420 PR 17420 is about cross-compiling third-party extension modules. If your problem is just cross-compiling Python you should stick to a solution that only fixes the problem described in the first paragraph of my first comment in https://github.com/python/cpython/issues/66913 Best regards. Xavier de Gaye On Wed, Jun 15, 2022 at 5:49 PM Gregory P. Smith <g...@krypto.org> wrote: > -cc:help (bcc) > > FWIW the thing to do to move this forward is to open a new PR. Patches > attached to an email are lost like tears in the rain. > > What you describe of cross compilation where host and target triples > appear the same but use different libraries is a valid cross compilation > case. But doesn't surprise me that there are bugs given most people never > have such a setup. Even in an "every build should be a cross build" world > (which we sadly don't have) it being broken may not show up. > > -gps > > On Wed, Jun 15, 2022 at 8:28 AM Victor Stinner <vstin...@python.org> > wrote: > >> Hi, >> >> While this problem is causing you a lot of troubles, I never had to >> cross compile Python, and I guess that it's the case for most people. >> Changing the Python build system and distutils is stressful since it >> can break Python for the majority of users, rather than leaving the >> minority of users with an old bug. So far, nobody was brave enough to >> "break" the system for cross compilation. >> >> Moreover, as far as I know, cross compiling Python works for the >> common case: different platform triplet. Only the corner case of the >> same triple is causing troubles. >> >> https://github.com/python/cpython/issues/66913 doesn't explain how to >> reproduce the issue, it only gives some info about what doesn't work. >> I don't know how to reproduce the issue. Please comment the issue. >> >> To cross compile Python, I found these documentations: >> >> * >> https://docs.python.org/dev/using/configure.html#cross-compiling-options >> * WASM: https://github.com/python/cpython/blob/main/Tools/wasm/README.md >> >> Currently, setup.py checks for: >> >> CROSS_COMPILING = ("_PYTHON_HOST_PLATFORM" in os.environ) >> >> Victor >> >> >> On Tue, Jun 14, 2022 at 1:49 AM Dave Blanchard <d...@killthe.net> wrote: >> > Here's what's happening. This is a very old problem reported ages ago >> which has never been fixed. If I set the target arch to i686 (on an x86_64 >> build system) Python will cross-compile and bootstrap just fine. But if the >> host and build triple are the same, then the problem will occur. Python >> seems to be ASSuming that if the build and host triple match (in this case, >> both being 'x86_64-linux-gnu') therefore the host and build libraries are >> binary-compatible--which is NOT actually the case when one is >> cross-compiling to a different libc, for example. Actually it's kind of >> brain dead how this is implemented. >> > >> > Some prior discussions/years-old bug reports: >> > >> > https://bugs.python.org/issue39399 >> > https://bugs.python.org/issue22724 >> > https://bugs.gentoo.org/705970 >> > >> > In those links, various hacks are attempted with various degrees of >> success, but then Xavier de Gaye reworked the build system, apparently >> fixing the problem with this pull request in Dec. 2019: >> > >> > https://github.com/python/cpython/pull/17420 >> > >> > Unfortunately he became annoyed in the comments, seemingly mostly due >> to the lack of interest from Python to actually do anything about this >> problem, and cancelled his pull request. His fix was never implemented, and >> Python cross-compiling remains broken to this day. >> > >> > I downloaded his patches, made a minor fix or two, and merged them all >> together into the one patch attached to this email. When applied to both my >> build system and target Python, this problem seems to be resolved, for me >> at least. I'll know more later tonight as I get further into the distro >> build process. >> > >> > It's surprising to hear that cross-compiling Python would be any kind >> of "unusual" thing, considering this is something that *always* has to be >> done any time one is bootstrapping anything on a new or different system. >> It surprises me further to see that Python actually requires the *minor* >> version number to be the same for bootstrapping, also. So not only is >> Python 3 essentially a different language from Python 2, each point release >> is different and incompatible also. Amazing. >> > >> > I guess this shouldn't be surprising, after all of the other >> questionable design decisions this project has made over the years. I >> probably also shouldn't be surprised to see such an incredibly important >> bug going unfixed after all this time. It's Python--by far the #1 biggest >> annoyance and pain in the ass out of the 1,000+ packages on my distro, >> ranking just above CUPS and Texlive. >> > >> > Dave >> > >> > >> > On Mon, 13 Jun 2022 16:12:26 -0500 (CDT) >> > Matthew Dixon Cowles <m...@mondoinfo.com> wrote: >> > >> > > Dear Dave, >> > > >> > > > Hello, I'm trying to cross compile a new version of my Linux system >> > > > with some upgraded packages, including a new Glibc. >> > > >> > > I've never had to do that and I am beginning to suspect, from the >> > > lack of replies here better than this one, that nobody else here has >> > > had to either. >> > > >> > > > I've hit a major snag with Python 3.7 (also tried 3.9 with same >> > > > result) which makes it through the compile OK, but then bombs when >> > > > running ensurepip at the end. >> > > >> > > If it were me, I'd set --with-ensurepip to no, declare victory, and >> > > run ensurepip on the target machine. >> > > >> > > I haven't been able to find any very good evidence, but I wouldn't be >> > > surprised if the option to turn ensurepip off is there to help out >> > > with cross-compiling. For example, here it's being turned off for >> > > compiling to web assembly: >> > > >> > > https://t.ly/_ZE3 >> > > >> > > (alternatively: >> > > >> > > https://github.com/python/cpython/commit/ >> > > 9deb83468c56c7484645e6e3a6d0183cd6a0afd7 >> > > >> > > ) >> > > >> > > which looks to me a lot like what you're doing. >> > > >> > > What seems to be happening is that in Lib/esurepip/__init__.py is >> > > calling run_module() in Lib/runpy.py and that's calling >> > > _run_module_code() which is getting the new, but wrong libraries. >> > > >> > > I suspect that it's possible to hack that to do what you want, but as >> > > far as a moderately close look tells me, it's not written with >> > > cross-compiling in mind. If I had to do make it work, I'd break out >> > > into the debugger and fiddle around on a mostly trial-and-error basis. >> > > >> > > Even then, I'd have a hacked version of ensurepip/__init__.py and/or >> > > runpy.py, which I'd want to replace with the originals in the end. >> > > >> > > I'm pretty sure that running ensurepip on the target would be easier. >> > > >> > > If that's not useful to you, let us know what you think and I'll try >> > > to think some more. >> > > >> > > Regards, >> > > Matt >> > > >> > >> > >> > -- >> > Dave Blanchard <d...@killthe.net> >> > _______________________________________________ >> > Python-Dev mailing list -- python-dev@python.org >> > To unsubscribe send an email to python-dev-le...@python.org >> > https://mail.python.org/mailman3/lists/python-dev.python.org/ >> > Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/MS5RVXQWOTYBDDRYFXU5RFGMBKABPYPG/ >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> >> -- >> Night gathers, and now my watch begins. It shall not end until my death. >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/MIK4QRZZZCM7LAGPAFSYSIW7T6JWISSE/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SATAFPRLT4VFJZJK353NHSDQW54LDWLS/ Code of Conduct: http://python.org/psf/codeofconduct/
