What version of glibc is Python using?

[Ian Kelly]

On Sat, Oct 12, 2013 at 9:59 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 10/12/2013 7: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.
>
>
> Was this always presence and missed, or has it been added in say, the last
> 10 years?

Reading the docs more closely, I think that the function is actually
working as intended.  It says that it determines "the libc version
against which the file executable (defaults to the Python interpreter)
is linked" -- or in other words, the minimum compatible libc version,
NOT the libc version that is currently loaded.

So I think that a patch to replace this with gnu_get_libc_version()
should be rejected, since it would change the documented behavior of
the function.  It may be worth considering adding an additional
function that matches the OP's expectations, but since it would just
be a simple ctypes wrapper it is probably best done by the user.