Target libc based suffix (-musl/-gnu) in PLATFORM_TRIPLET is chosen based on build machine configuration instead of configuration of the target

[autobakterie]

That, as an example, leads to cpython 3.9.13 build failing¹ when cross-compiling on AMD64 Linux with glibc for mpc8548 Linux (OpenWrt) with musl.

As already described and confirmed as a bug in #24502 (comment) :

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² which refers to the target platform that might differ from the build platform in case of cross-compilation.

I'm creating this as a separate issue concerning a particular problem, but I think this also contributes to existing discussion in #87278 .

Linked PRs

• gh-95855: Refactor platform triplet detection code, add detection for MIPS soft float and musl libc #107221

Footnotes

1. "internal configure error for the platform triplet, please file a bug report" ↩

2. https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Canonicalizing.html ↩

[tiran]

I have been looking into the issue. The current code has more problems and #24502 should not have been accepted in its state. The lines

cpython/configure.ac

Lines 1076 to 1080 in 2fa03b1

	case "$build_os" in
	linux-musl*)
	PLATFORM_TRIPLET=`echo "$PLATFORM_TRIPLET" | sed 's/linux-gnu/linux-musl/'`
	;;
	esac

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.

[jefferyto]

For example glibc mips64el-linux-gnuabi64 should be musl mips64el-linux-musl, not mips64el-linux-muslabi64.

I believe musl for mips64 can be compiled for o32/n32 ABIs so mips64el-linux-muslabi64 would be the most explicit/appropriate, but I also think the current approach is a hack.

Edit: I'm incorrect on both points: musl for mips64 can be built for n64/n32 (not o32); mips64el-linux-musl is correct (with n64 as the most common/default abi for mips64).