Re: [Python-Help] Unable to bootstrap Python 3 install
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 <matt@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:
(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 <dave@killthe.net>
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 <dave@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 <matt@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:
(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 <dave@killthe.net> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/MS5RVXQW... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
-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 <vstinner@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
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
On Tue, Jun 14, 2022 at 1:49 AM Dave Blanchard <dave@killthe.net> wrote: 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 <matt@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:
(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 <dave@killthe.net> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/MS5RVXQW...
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-leave@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/MIK4QRZZ... Code of Conduct: http://python.org/psf/codeofconduct/
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 <greg@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 <vstinner@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
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
On Tue, Jun 14, 2022 at 1:49 AM Dave Blanchard <dave@killthe.net> wrote: 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 <matt@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:
(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 <dave@killthe.net> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/MS5RVXQW...
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-leave@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/MIK4QRZZ... Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jun 16, 2022 at 4:29 PM Xavier de Gaye <xdegaye@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 -- Night gathers, and now my watch begins. It shall not end until my death.
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 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
we would like to have clear instructions how to reproduce the problem ourselves It is difficult to miss the irony in this sentence because at the time of
Hi Christian, Some of the answers to your questions may possibly be found in PR 1629: bpo-30386: Add a build infrastructure for Android https://github.com/python/cpython/pull/1629 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: https://github.com/python/cpython/blob/0a51515a634872275aaeafb2e8a198289e6cf... 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 <christian@python.org> wrote:
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 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
On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes <christian@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 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.
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. On Fri, 17 Jun 2022 13:10:28 +0200 Victor Stinner <vstinner@python.org> wrote:
On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes <christian@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 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.
-- Nathan Cline <nate@killthe.net>
participants (6)
-
Christian Heimes -
Dave Blanchard -
Gregory P. Smith -
Nathan Cline -
Victor Stinner -
Xavier de Gaye