SOABI on Linux does not distinguish between GNU libc and musl libc #87278
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = None closed_at = None created_at = <Date 2021-02-03.09:26:13.443> labels = ['interpreter-core', 'type-bug', '3.9', '3.10', '3.11'] title = 'SOABI on Linux does not distinguish between GNU libc and musl libc' updated_at = <Date 2022-01-29.00:29:09.330> user = 'https://github.com/ncopa'
activity = <Date 2022-01-29.00:29:09.330> actor = 'eric.araujo' assignee = 'none' closed = False closed_date = None closer = None components = ['Interpreter Core'] creation = <Date 2021-02-03.09:26:13.443> creator = 'ncopa' dependencies = ['46390'] files =  hgrepos =  issue_num = 43112 keywords = ['patch'] message_count = 16.0 messages = ['386183', '386184', '386186', '386192', '386194', '386196', '386197', '386710', '386722', '386739', '386797', '405471', '406858', '406939', '410646', '412042'] nosy_count = 12.0 nosy_names = ['christian.heimes', 'piro', 'eric.araujo', 'Arfrever', 'ncopa', 'Henry Schreiner', 'uranusjr', 'miss-islington', 'tianon', 'dave-shawley', 'h-vetinari', 'olivierlefloch'] pr_nums = ['24502', '31001'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue43112' versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
The text was updated successfully, but these errors were encountered:
The SOABI does not make any difference between GNU libc and musl libc.
Using official docker images:
# debian build with GNU libc
# alpine build with musl libc
Both ends with
This affects the extension suffix:
$ docker run --rm python:slim python-config --extension-suffix .cpython-39-x86_64-linux-gnu.so $ docker run --rm python:alpine python-config --extension-suffix .cpython-39-x86_64-linux-gnu.so
Which again affects the pre-compiled binary wheels, and binary modules built with musl libc gets mixed up with the GNU libc modules due to the -gnu.so suffix.
The source of the problem is that the
So when building python with musl libc the PLATFORM_TRIPLET always sets
output from configure run on musl system:
A first step in fixing this would be to make sure that we only set -gnu when __GLIBC__ is defined:
diff --git a/configure.ac b/configure.ac index 1f5a008388..1b4690c90f 100644 --- a/configure.ac +++ b/configure.ac @@ -726,7 +726,7 @@ cat >> conftest.c <<EOF #undef unix #if defined(__ANDROID__) # Android is not a multiarch system. -#elif defined(__linux__) +#elif defined(__linux__) && defined (__GLIBC__) # if defined(__x86_64__) && defined(__LP64__) x86_64-linux-gnu
But that would make build with musl fail with "unknown platform triplet".
Not sure what the proper fix would be, but one way to extract the suffix from
The suffix "-gnu" does not stand for "glibc".
The triplet defines the calling convention. For example x86_64-linux-gnu means x86_64 / AMD64 CPU architecture, Linux, with standard GNU / GCC calling convention. Other calling conventions are "x86_64-linux-gnux32" for X32 on AMD64 and "arm-linux-gnueabihf" for 32bit ARM with extended ABI and hardware float support.
The triplets are standardized beyond Python. Debian's multiarch page lists and explains a large amount of triplets, https://wiki.debian.org/Multiarch/Tuples
SOABI basically contains the CPU architecture and Kernel ABI. The libc ABI is yet another dimension that is not encoded in the shared library ABI.
The libc ABI is more complex than just glibc or musl. You need to include the ABI version of all core components. For example manylinux2014 defines the ABI for glibc as GLIBC_2.17, CXXABI_1.3.7, CXXABI_TM_1, GLIBCXX_3.4.19, GCC_4.8.0.
As a rule of thumb, a SOABI like ".cpython-39-x86_64-linux-gnu.so" only works the current host. You cannot safely move the file to another host or bump the SO version of any library, unless you ensure that the ABIs of all libraries are compatible.
The referenced https://wiki.debian.org/Multiarch/Tuples doc says:
Since GNU libc and musl libc are not ABI compatible they can not share same unique identifier. I think replacing -gnu with -musl makes sense.
No. But there is nothing preventing me to have the libc runtimes installed in parallel with glibc.
And it is not common that people copy libc.so.6 (with friends) to their alpine docker images to run both in same container. If that is a good idea is other discussion.
I do understand that full ABI compatibility also may involve libc ABI version, but I think that is a slightly different problem. Newer versions of glibc and musl libc are backwards compatible. You can expect a binary built with old libc version to run with new libc. But you cannot expect a binary built with musl libc to run with gnu libc.
gcc recognizes -linux-musl as a valid platform tuple different that differs from -linux-gnu:
The standard autotools' config.guess1 also recognizes -musl as different platform.
$ ./config.guess x86_64-pc-linux-musl
So I think it makes sense to treat *-linux-musl as a different platform than *-linux-gnu.
If you still insist that this is only about calling convention and not platform, then I think you should at least clarify that in the configure.ac script to avoid confusion:
sed -i -e 's/PLATFORM_TRIPLET/CALLING_CONVENTION_TRIPLET/g' -e 's/platform triplet/calling convention triplet/g' configure.ac
I stand corrected. The last element in the platform triplet does seem to indicate libc.
Is there any formal definition of the platform triplet or is it defined by GCC's reference implementation? A quick search didn't reveal any decisive results.
The next steps here would be:
Let's continue this on https://discuss.python.org/t/wheels-for-musl-alpine/7084
This mentions some examples for musl triplets/tuples:
It points to https://github.com/richfelker/musl-cross-make/blob/master/README.md#supported-targets which I think is the best documentation. (Rich Felker is the author and lead developer or musl libc).
I'm not sure its worth spend time on uClibc which does not seem to have any commits at all since 2015. https://git.uclibc.org/uClibc/log/
We will work on our side on buildbot with Alpine linux.
Thank you for being understanding.
While original uClibc is not maintained, its fork called uClibc-ng is supposedly binary-compatible with uClibc and is still somehow maintained:
https://www.uclibc.org/news.html also says:
libc part of platform tuple on uClibc-ng systems is expected to be "uclibc".
Can anyone problem examples that it’s not an option to continue using the “technically incorrect”
If that’s correct, I feel “being able to distinguish between modules built against musl and glibc” should be a feature request and only implemented for 3.11+, while versions 3.10 and prior continue to use
We had a call and have a potential path forward. Quick summary:
How does that sound?
In order to work around this limitation, packaging is forced to call