This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author njs
Recipients Thomas.Waldmann, lemburg, njs
Date 2016-07-10.06:00:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468130448.89.0.0981390533288.issue26544@psf.upfronthosting.co.za>
In-reply-to
Content
We just ran into this in pip -- https://github.com/pypa/pip/pull/3836

I'd really recommend dropping the current "grovel through the binary doing a regex search" strategy -- it's incredibly error prone, and AFAICT doesn't really give any value. This code OTOH reliably lets you detect glibc and gives the exact version number with no fuss:
   https://github.com/pypa/pip/blob/master/pip/utils/glibc.py#L9

What about non-glibc systems? Unfortunately the current libc_ver() turns out not to work well for those either. Attached is a CSV file showing the return value of ~1.2 billion calls to platform.libc_ver() by the last 6 months of pip users. You can see that the current code basically never returns anything useful for non-glibc platforms. (The one exception is that it seems to be able to detect uclibc 0.9.32 and label it as "libc 0.9.32".)

Don't get me wrong: it'd be really really useful if there were some way to detect and distinguish between the common non-glibc libcs like musl/bionic/uclibc/..., but I'm not sure how to do that -- and unfortunately the current code definitely doesn't do the job :-(.
History
Date User Action Args
2016-07-10 06:00:49njssetrecipients: + njs, lemburg, Thomas.Waldmann
2016-07-10 06:00:48njssetmessageid: <1468130448.89.0.0981390533288.issue26544@psf.upfronthosting.co.za>
2016-07-10 06:00:48njslinkissue26544 messages
2016-07-10 06:00:47njscreate