platform.libc_ver() returns no information on Alpine Linux

@The-Compiler

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']

Linked PRs

gh-87414: add musl support to platform.libc_ver #103784

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.

@Omer.Katz

This issue should be fixed, feel free to submit the PR

Any progress on this? Is there any other function to check whether the host system is using musl or glibc?

Adapt musl recognition

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

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.

This issue also causes platform.platform() to return a nonsensical output: Linux-6.15.6-0-stable-x86_64-with (The -with doesn't makes sense when libcname+libcversion is empty)

Edit: tested a version without #131313 , probably works fine with

~/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')

Navigation Menu

Repository navigation

platform.libc_ver() returns no information on Alpine Linux #87414

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

platform.libc_ver() returns no information on Alpine Linux #87414

Description

Linked PRs

Activity

thedrow commented on Feb 18, 2021

corona10 commented on Feb 20, 2021

mara004 commented on Apr 30, 2022

mara004 commented on Jan 19, 2023

zware commented on Apr 28, 2025

sertonix commented on Jul 17, 2025

zware commented on Sep 6, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions