Repository navigation
platform.libc_ver() returns no information on Alpine Linux #87414
Description
| BPO | 43248 |
|---|---|
| Nosy | @The-Compiler, @thedrow, @corona10 |
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
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-02-18.11:13:38.696>
labels = ['3.8']
title = 'platform.libc_ver() returns no information on Alpine Linux'
updated_at = <Date 2021-07-05.08:01:18.532>
user = 'https://github.com/thedrow'bugs.python.org fields:
activity = <Date 2021-07-05.08:01:18.532>
actor = 'The Compiler'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2021-02-18.11:13:38.696>
creator = 'Omer.Katz'
dependencies = []
files = []
hgrepos = []
issue_num = 43248
keywords = []
message_count = 2.0
messages = ['387211', '387396']
nosy_count = 3.0
nosy_names = ['The Compiler', 'Omer.Katz', 'corona10']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue43248'
versions = ['Python 3.8']
Activity
thedrow commentedon Feb 18, 2021
When calling platform.libc_ver() on Alpine I get the following tuple: ('', '')
Instead, I expect to get ('muslc', '<version number>') or an exception if the libc type & version cannot be detected.
If one of them is not detected, the returned value shouldn't be an empty string but None.
The current API is not what most people would expect it to be.
This is verified on Python 3.8 since that's the latest one available on Alpine.
This code reliably detects musl libc and its version: https://github.com/lovell/detect-libc/blob/master/lib/detect-libc.js
I'd be happy to contribute a PR if needed.
corona10 commentedon Feb 20, 2021
@Omer.Katz
This issue should be fixed, feel free to submit the PR
mara004 commentedon Apr 30, 2022
Any progress on this? Is there any other function to check whether the host system is using musl or glibc?
Adapt musl recognition
mara004 commentedon Jan 19, 2023
How about just integrating packaging's musl detection code into the standard library?
https://github.com/pypa/packaging/blob/main/src/packaging/_musllinux.py
(Actually, I'm a bit surprised this wasn't done directly on the implementation of PEP 656.)
fix[util]: remove is_libc_musl
fix[util]: remove is_libc_musl
zware commentedon Apr 28, 2025
Strictly speaking, this issue has been fixed by GH-131313. However, GH-103784 is still open which may or may not improve on the situation, and the commit message from GH-131313 mentions that WASI/Emscripten support is still lacking.
sertonix commentedon Jul 17, 2025
This issue also causes
platform.platform()to return a nonsensical output:Linux-6.15.6-0-stable-x86_64-with(The-withdoesn't makes sense whenlibcname+libcversionis empty)Edit: tested a version without #131313 , probably works fine with
zware commentedon Sep 6, 2025
~/cpython $ ./python Python 3.15.0a0 (heads/main:c117b03, Sep 6 2025, 22:03:51) [GCC 14.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.platform() 'Linux-6.15.10-200.fc42.x86_64-x86_64-with-musl1.2.5' >>> platform.libc_ver() ('musl', '1.2.5')