[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install
294 views
Skip to first unread message
Dave Blanchard
Jun 13, 2022, 7:50:27 PM6/13/22
to he...@python.org, Matthew Dixon Cowles, xde...@gmail.com, pytho...@python.org
Thanks for your reply Matt.
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 <ma...@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 <da...@killthe.net>
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 <ma...@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 <da...@killthe.net>
Victor Stinner
Jun 15, 2022, 11:28:02 AM6/15/22
to Dave Blanchard, he...@python.org, Matthew Dixon Cowles, Xavier de Gaye, Python Dev
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
> _______________________________________________
> Python-Dev mailing list -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/pytho...@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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/MIK4QRZZZCM7LAGPAFSYSIW7T6JWISSE/
Code of Conduct: http://python.org/psf/codeofconduct/
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
> Python-Dev mailing list -- pytho...@python.org
> To unsubscribe send an email to python-d...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/pytho...@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 -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/MIK4QRZZZCM7LAGPAFSYSIW7T6JWISSE/
Code of Conduct: http://python.org/psf/codeofconduct/
Gregory P. Smith
Jun 15, 2022, 11:54:45 AM6/15/22
to Victor Stinner, Dave Blanchard, Matthew Dixon Cowles, Xavier de Gaye, Python Dev
-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
Victor Stinner
Jun 16, 2022, 11:08:02 AM6/16/22
to Xavier de Gaye, Dave Blanchard, Matthew Dixon Cowles, Python Dev
On Thu, Jun 16, 2022 at 4:29 PM Xavier de Gaye <xde...@gmail.com> wrote:
> 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.
You misunderstood me. I didn't say that the issue must not be fixed. I
only tried to explain why it was not fixed yet.
> 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 !
Is there a way to reproduce the issue without Android? Like building
Python on x86-64 for musl on a system using glibc?
> 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.
That's interesting, since distutils is scheduled from removal in Python 3.12.
Victor
> 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.
You misunderstood me. I didn't say that the issue must not be fixed. I
only tried to explain why it was not fixed yet.
> 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 !
Is there a way to reproduce the issue without Android? Like building
Python on x86-64 for musl on a system using glibc?
> 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.
That's interesting, since distutils is scheduled from removal in Python 3.12.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/B74YHEAKQZF2XZEOH6SKZRHXQGU4A5OD/
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Xavier de Gaye
Jun 16, 2022, 1:37:14 PM6/16/22
to Gregory P. Smith, Victor Stinner, Dave Blanchard, Matthew Dixon Cowles, Python Dev
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.
> 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
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
Christian Heimes
Jun 16, 2022, 1:59:25 PM6/16/22
to Xavier de Gaye, Gregory P. Smith, Victor Stinner, Dave Blanchard, Matthew Dixon Cowles, Python Dev
On 16/06/2022 16.29, Xavier de Gaye wrote:
> Victor Stinner wrote:
> > https://github.com/python/cpython/issues/66913
> <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.
What Victor means that we would like to have clear instructions how to
> Victor Stinner wrote:
> > https://github.com/python/cpython/issues/66913
> <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.
reproduce the problem ourselves. Could you please provide step by step
instructions how I could set up a build environment on a X86_64 PC with
a standard Linux distro (Fedora, Debian/Ubuntu)?
What packages have to be installed? Do I have to download any extra
packages? How do I have to set up my build environment? Which commands
do I have to execute? Is there a container image available that comes
with everything pre-installed?
You mentioned well-documented process by the Android team. Could you
please provide links to the relevant documents?
Christian
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/WNEFUJZH32LSNBX75QBLP6X6XZQVAHNK/
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Victor Stinner
Jun 17, 2022, 7:16:32 AM6/17/22
to Christian Heimes, Xavier de Gaye, Dave Blanchard, Matthew Dixon Cowles, Python Dev
On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes <chri...@python.org> wrote:
> What Victor means that we would like to have clear instructions how to
> reproduce the problem ourselves. Could you please provide step by step
> instructions how I could set up a build environment on a X86_64 PC with
> a standard Linux distro (Fedora, Debian/Ubuntu)?
>
> What packages have to be installed? Do I have to download any extra
> packages? How do I have to set up my build environment? Which commands
> do I have to execute? Is there a container image available that comes
> with everything pre-installed?
I don't know if it helps, but I managed to build Python linked to the
> What Victor means that we would like to have clear instructions how to
> reproduce the problem ourselves. Could you please provide step by step
> instructions how I could set up a build environment on a X86_64 PC with
> a standard Linux distro (Fedora, Debian/Ubuntu)?
>
> What packages have to be installed? Do I have to download any extra
> packages? How do I have to set up my build environment? Which commands
> do I have to execute? Is there a container image available that comes
> with everything pre-installed?
musl libc using musl-gcc.
The build and the built Python just work on Fedora 36. It doesn't seem
to reproduce the discussed build issue.
Commands:
---
sudo dnf install musl-libc musl-gcc
git clean -fdx
./configure --with-pydebug CC=musl-gcc LD=musl-gcc
make
---
Interesting part of the build:
---
Platform "x86_64-pc-linux-musl" with compiler "gcc" is not supported by the
CPython core team, see https://peps.python.org/pep-0011/ for more information.
---
The executable is linked to ld-musl-x86_64.so.1:
---
$ ldd ./python
linux-vdso.so.1 (0x00007fffbd6b6000)
ld-musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x00007f5253669000)
---
Python works as expected:
---
$ ./python
Python 3.12.0a0 (heads/main:4beee0c7b0, Jun 17 2022, 12:23:58) [GCC
12.1.1 20220507 (Red Hat 12.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
2
---
The _struct extension works as expected and is linked to musl:
---
$ ./python
>>> import _struct
>>> _struct.pack('I', 4)
b'\x04\x00\x00\x00'
>>> _struct
<module '_struct' from
'/home/vstinner/python/main/build/lib.linux-x86_64-3.12-pydebug/_struct.cpython-312d-x86_64-linux-musl.so'>
$ ldd /home/vstinner/python/main/build/lib.linux-x86_64-3.12-pydebug/_struct.cpython-312d-x86_64-linux-musl.so
linux-vdso.so.1 (0x00007ffedb5fd000)
ld-musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x00007f4be8cd0000)
---
There are some compiler warnings and build errors, but I didn't pay
attention to them since I was interested by the discussed build issue.
---
I also tried something closer to "cross-compiler", but I got it wrong,
since Python is still linked to the glibc, not to musl. Again, I don't
reproduce the issue.
By the way, what is the issue? Is it a build error?
bpo-39399 mentions the error "ImportError: libc.so: cannot open shared
object file" on "import struct".
Get Python 3.12 on the host (installed in /opt/py3.12):
---
git clean -fdx
./configure --prefix=/opt/py3.12
make
make install
---
Fake buildchain:
---
$ mkdir cross-build
$ cd cross-build/
$ ln -s /usr/bin/readelf x86_64-pc-linux-musl-readelf
$ cd ..
---
Build:
---
$ sudo dnf install musl-libc # install musl
$ cat config-musl
ac_cv_file__dev_ptmx=no
ac_cv_file__dev_ptc=no
$ cat build.sh
set -e -x
PATH=$PATH:cross-build/ \
CONFIG_SITE=config-musl \
./configure \
--with-build-python=/opt/py3.12/bin/python3.12 \
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-musl \
--with-pydebug \
--disable-ipv6 \
--cache-file=../configure-musl.cache
$ ./build.sh
$ make
---
Sadly, the built executable is linked to the glibc:
---
$ ldd ./python
linux-vdso.so.1 (0x00007ffcd89d0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f54d2a60000)
libc.so.6 => /lib64/libc.so.6 (0x00007f54d285f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f54d2b62000)
---
Well, since glibc and musl are available and just work on my system,
I'm not sure if my test makes any sense :-) Should the target libc not
work on the host to reproduce the issue?
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/3AKU5VJ5OBFZ7MVS4UWYLUAW5ZGGACIS/
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Xavier de Gaye
Jun 17, 2022, 2:52:52 PM6/17/22
to Christian Heimes, Victor Stinner, Dave Blanchard, Matthew Dixon Cowles, Python Dev
Hi Christian,
Some of the answers to your questions may possibly be found in PR 1629: bpo-30386: Add a build infrastructure for Android
Please note that the purpose of this PR was not to give clear instructions on how to cross-compile android, but to add an android buildbot to the Python buildbots, hence its relative complexity.
The README created by this PR provide some of the links that you are looking for:
> we would like to have clear instructions how to
> reproduce the problem ourselves
> reproduce the problem ourselves
It is difficult to miss the irony in this sentence because at the time of this PR I was a Python core developer and the 'we' in your sentence would have included me then. So at this time 'we' had all the knowledge to fulfill your requests. The irony is that the reason why I resigned from being a core developer was because of the handling of this PR.
Xavier de Gaye
On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes <chri...@python.org> wrote:
Nathan Cline
Jun 17, 2022, 2:53:23 PM6/17/22
to Victor Stinner, Christian Heimes, Xavier de Gaye, Dave Blanchard, Matthew Dixon Cowles, Python Dev
Step one: build a GCC cross compiler which is linked to a newer glibc than what your build system is running, or a different version of musl if that's what you're using.
Step two: cross-compile Python against the new libc exactly the same way you would cross-compile any other program, using the same triple for build/host/target, such as x86_64-linux-gnu.
Step three: watch the build almost complete, then enjoy the fireworks at the end when Python attempts to load freshly compiled .so objects into the host system Python, crashing and burning.
Step four: apply Xavier's patch, fix the problem, and then move on with your life.
--
Nathan Cline <na...@killthe.net>
Step two: cross-compile Python against the new libc exactly the same way you would cross-compile any other program, using the same triple for build/host/target, such as x86_64-linux-gnu.
Step three: watch the build almost complete, then enjoy the fireworks at the end when Python attempts to load freshly compiled .so objects into the host system Python, crashing and burning.
Step four: apply Xavier's patch, fix the problem, and then move on with your life.
Nathan Cline <na...@killthe.net>
_______________________________________________
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/pytho...@python.org/message/UE6AJ7L7RDMMDEXEVVIP7AXCTYLC25T5/
Python-Dev mailing list -- pytho...@python.org
To unsubscribe send an email to python-d...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Reply all
Reply to author
Forward
0 new messages