What version of glibc is Python using?

[John Nagle]

On 10/12/2013 4:43 AM, Ian Kelly wrote:
> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 10/12/2013 3:53 AM, Christian Gollwitzer wrote:
>>>
>>> That function is really bogus. It states itself, that it has "intimate
>>> knowledge of how different libc versions add symbols to the executable
>>> and thus is probably only useable for executables compiled using gcc"
>>> which is just another way of saying "it'll become outdated and broken
>>> soon". It's not even done by reading the symbol table, it opens the
>>> binary and matches a RE *shocked* I would have expected such hacks in a
>>> shell script.
>>>
>>> glibc has a function for this:
>>>
>>>      gnu_get_libc_version ()
>>>
>>> which should be used.
>>
>>
>> So *please* submit a patch with explanation.
> 
> Easier said than done.  The module is currently written in pure
> Python, and the comment "Note: Please keep this module compatible to
> Python 1.5.2" would appear to rule out the use of ctypes to call the
> glibc function.  I wonder though whether that comment is really still
> appropriate.

   What a mess.  It only "works" on Linux,
it only works with GCC, and there it returns bogus results.

   Amusingly, there was a fix in 2011 to speed up
platform.libc_ver () by having it read bigger blocks:

http://code.activestate.com/lists/python-checkins/100109/

It still got the wrong answer, but it's faster.

There's a bug report that it doesn't work right on Solaris:

http://comments.gmane.org/gmane.comp.python.gis/870

It fails on Cygwin ("wontfix")
http://bugs.python.org/issue928297

The result under GenToo is bogus:

http://archives.gentoo.org/gentoo-user/msg_b676eccb5fc00cb051b7423db1b5a9f7.xml

There are several programs which fetch this info and
display it, or send it in with crash reports, but
I haven't found any that actually use the result
for anything.  I'd suggest deprecating it and
documenting that.

				John Nagle