What version of glibc is Python using?

[Terry Reedy]

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?

>> 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.

I do not see that line in the 3.4 version. Anyway, submit a patch with 
explanation and assign the issue to "lemburg", who is the maintainer. 
(He sells 3rd party add-ons and obvious uses this function for those.) 
He can decide if a conditional (>2.4) is needed.

-- 
Terry Jan Reedy