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 vstinner
Recipients jwilk, lemburg, serhiy.storchaka, vstinner
Date 2018-12-05.14:59:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544021971.32.0.788709270274.issue35389@psf.upfronthosting.co.za>
In-reply-to
Content
> Nice. I never liked the "parse the executable approach", but there wasn't anything better available at the time.

Aha. Well, it's not perfect but it works and was fast enough (since libc_ver() is never used in performance critical code) :-)

I'm now curious and looked at the history of this feature.

"man confstr" says:

> _CS_GNU_LIBC_VERSION (GNU C library only; since glibc 2.3.2)

glibc 2.3.2 has been released in March 2003, so it's fine, we should get this constant in most "modern" Linux (using glibc) in 2018 :-)

man gnu_get_libc_version says:

> These functions first appeared in glibc in version 2.1.

glibc 2.1 has been released in Feb 1999. Using this function might provide even better compatibility but I'm not sure that it's worth it to use it. As I wrote, I prefer to not write a new function C, if os.confstr() can already be used in pure Python!

Sadly, these functions (confstr(_CS_GNU_LIBC_VERSION) / gnu_get_libc_version()) are specific to glibc. Sorry, I'm not interested to support other libc, I mostly care about Fedora, sorry :-)
History
Date User Action Args
2018-12-05 14:59:32vstinnersetrecipients: + vstinner, lemburg, jwilk, serhiy.storchaka
2018-12-05 14:59:31vstinnersetmessageid: <1544021971.32.0.788709270274.issue35389@psf.upfronthosting.co.za>
2018-12-05 14:59:31vstinnerlinkissue35389 messages
2018-12-05 14:59:31vstinnercreate