When trying to compile the python 3.11 betas with musl and clang, I run into a configure error saying "internal configure error for the platform triplet, please file a bug report." I looked into this a bit deeper and found that python runs an internal test to figure out the platform triplet and then asks the compiler for one as well using `--print-multiarch` and compares them. On gcc, the `--print-multiarch` flag returns nothing but on and python compiles fine. With clang, x86_64-linux-gnu is returned when the build system expects x86_64-linux-musl causing the configure error. I found an open issue for clang with a patch that would make the triplet match what python expects and makes the python 3.11 betas compile, but this python 3.10 fail to compile for a similar reason. (https://github.com/llvm/llvm-project/issues/51469 https://bugs.llvm.org/show_bug.cgi?id=52127) Reproducible: Always Steps to Reproduce: 1. Have a system with musl + clang 2. emerge python:3.11 with clang as the compiler Actual Results: configure: error: internal configure error for the platform triplet, please file a bug report Expected Results: python:3.11 compiles
Created attachment 796723 [details] emerge --info
Created attachment 796726 [details] build.log
Created attachment 796729 [details] config.log
*** Bug 863953 has been marked as a duplicate of this bug. ***
The PR here for sys-devel clang, https://github.com/gentoo/gentoo/pull/26806, fixes compilation for python 3.11 on musl + clang systems but it breaks older versions. Python 3.10, 3.9, and 3.8 don't detect linux-musl as the platform triplet and actually expects linux-gnu. Should I open a separate bug report for this? I've attached the build.log and config.log for python 3.10.6 when building with the patch in the PR.
Created attachment 799215 [details] python 3.10.6 build.log
Created attachment 799217 [details] python 3.10.6 config.log
Solved with llvm 15
(In reply to Daniele Basso from comment #8) > Solved with llvm 15 Are you sure? It doesn't seem fixed to me. It looks like it may be fixed in the very-much-unreleased LLVM *16*.
Maybe you are right
Posting a bit more summary since Sam asked. yemou has already done a good job at describing the problem, so I'll skip that part. The issue seems to be with python, [this merge request](https://github.com/python/cpython/pull/24502) seems to be the main cause. I'll post a comment thread under that MR that seem to address the issue. ``` autobakterie comments: If I'm not mistaken, PLATFORM_TRIPLET should refer to the target platform on which cpython will run. If that is the case, the musl libc vs. glibc decision should be based on $host_os rather than $build_os as the former is based on autoconf's AC_CANONICAL_HOST macro [ 1 ] which refers to the target platform that might differ from build platform in case of cross-compilation. For example, the decision based on $build_os leads to cpython 3.9.13 build failing [ 2 ] when cross-compiling on AMD64 Linux with glibc for mpc8548 Linux (OpenWrt) with musl. (build runs correctly if $host_os is used) Footnotes [ 1 ]: https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Canonicalizing.html leftwards_arrow_with_hook [ 2 ]: "internal configure error for the platform triplet, please file a bug report" leftwards_arrow_with_hook tiran replies: Yes, the code is wrong. In fact the entire block should be revisited. We really should check for __GLIBC__ and use a heuristic to detect musl. Could you please open a new issue for the problem? ``` In [this comment](https://github.com/python/cpython/issues/95855#issuecomment-1215205611) developer tiran says "The current code has more problems and #24502 should not have been accepted in its state. The lines in configure.ac are a hack that just happens to generate correct platform triplet for most common platforms. It breaks for some platforms that are detected by our detection code. For example glibc mips64el-linux-gnuabi64 should be musl mips64el-linux-musl, not mips64el-linux-muslabi64." I've tried upstreaming the origin patch suggested by yemou, but the clang devs suggested that it's not the right way of going forward and python should follow debian tiplets instead. Nevertheless, both python and clang devs have acknowledged the issue and have made some commits relevant to this issue (I might me wrong). For clang, the have decided to Unsupport --print-multiarch (https://reviews.llvm.org/D133170). For python, I dont know if the commit is in master yet, but I found this commit relavent (https://github.com/tiran/cpython/commit/629b5a7d201db8f2f0ba2a1cf00cdcd33503855b)
(In reply to listout from comment #11) > Posting a bit more summary since Sam asked. yemou has already done a good > job at describing the problem, so I'll skip that part. > > The issue seems to be with python, [this merge > request](https://github.com/python/cpython/pull/24502) seems to be the main > cause. I'll post a comment thread under that MR that seem to address the > issue. > > ``` > autobakterie comments: > If I'm not mistaken, PLATFORM_TRIPLET should refer to the target > platform on which cpython will run. If that is the case, the musl libc > vs. glibc decision should be based on $host_os rather than $build_os as > the former is based on autoconf's AC_CANONICAL_HOST macro [ 1 ] which > refers to the target platform that might differ from build platform in > case of cross-compilation. > > For example, the decision based on $build_os leads to cpython 3.9.13 > build failing [ 2 ] when cross-compiling on AMD64 Linux with glibc for > mpc8548 Linux (OpenWrt) with musl. (build runs correctly if $host_os is > used) Footnotes > > [ 1 ]: > https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/ > Canonicalizing.html > leftwards_arrow_with_hook > > [ 2 ]: "internal configure error for the platform triplet, please file a > bug report" leftwards_arrow_with_hook > > tiran replies: > Yes, the code is wrong. In fact the entire block should be revisited. We > really should check for __GLIBC__ and use a heuristic to detect musl. > Could you please open a new issue for the problem? > ``` > > In [this > comment](https://github.com/python/cpython/issues/95855#issuecomment- > 1215205611) developer tiran says "The current code has more problems and > #24502 should not have been accepted in its state. The lines in configure.ac > are a hack that just happens to generate correct platform triplet for most > common platforms. It breaks for some platforms that are detected by our > detection code. For example glibc mips64el-linux-gnuabi64 should be musl > mips64el-linux-musl, not mips64el-linux-muslabi64." > > I've tried upstreaming the origin patch suggested by yemou, but the clang > devs suggested that it's not the right way of going forward and python > should follow debian tiplets instead. > > Nevertheless, both python and clang devs have acknowledged the issue and > have made some commits relevant to this issue (I might me wrong). For clang, > the have decided to Unsupport --print-multiarch > (https://reviews.llvm.org/D133170). For python, I dont know if the commit is > in master yet, but I found this commit relavent > (https://github.com/tiran/cpython/commit/ > 629b5a7d201db8f2f0ba2a1cf00cdcd33503855b) Also maybe have a look at this draft MR (https://github.com/python/cpython/pull/96001/files)?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9a0579d3b71b7715d11beb16efbc138e3254a1a commit d9a0579d3b71b7715d11beb16efbc138e3254a1a Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2022-09-09 07:59:12 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2022-09-09 08:00:24 +0000 dev-lang/python: Backport clang+musl build fix to 3.11.0_rc1_p2 Closes: https://bugs.gentoo.org/862888 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-lang/python/Manifest | 2 +- dev-lang/python/python-3.11.0_rc1_p2.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
