What version of glibc is Python using?

[John Nagle]

I'm trying to find out which version of glibc Python is using.
I need a fix that went into glibc 2.10 back in 2009.
(http://udrepper.livejournal.com/20948.html)

So I try the recommended way to do this, on a CentOS server:

/usr/local/bin/python2.7
Python 2.7.2 (default, Jan 18 2012, 10:47:23)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.libc_ver()
('glibc', '2.3')

This is telling me that the Python distribution built in 2012,
with a version of GCC released April 16, 2011, is using
glibc 2.3, released in October 2002. That can't be right.

I tried this on a different Linux machine, a desktop running
Ubuntu 12.04 LTS:

Python 2.7.3 (defualt, April 10 2013, 06:20:15)
[GCC 4.6.3] on linux2
('glibc', '2.7')

That version of glibc is from October 2007.

Where are these ancient versions coming from? They're
way out of sync with the GCC version.

John Nagle

[Christian Gollwitzer]

Am 12.10.13 08:34, schrieb John Nagle:

> I'm trying to find out which version of glibc Python is using.
> I need a fix that went into glibc 2.10 back in 2009.
> (http://udrepper.livejournal.com/20948.html)
>
> So I try the recommended way to do this, on a CentOS server:
>
> /usr/local/bin/python2.7
> Python 2.7.2 (default, Jan 18 2012, 10:47:23)
> [GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import platform
>>>> platform.libc_ver()
> ('glibc', '2.3')

Try

ldd /usr/local/bin/python2.7

Then execute the reported libc.so, which gives you some information.

Christian

[John Nagle]

Thanks for the quick reply. That returned:

/lib64/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.6 20110731 (Red Hat 4.4.6-3).
Compiled on a Linux 2.6.32 system on 2011-12-06.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Much more helpful. I have a good version of libc, and
can now work on my DNS resolver problem.

Why is the info from "plaform.libc_ver()" so bogus?

John Nagle

[Ned Deily]

In article <l3as90$5bk$1...@dont-email.me>, John Nagle <na...@animats.com>
wrote:
[...]

> Why is the info from "plaform.libc_ver()" so bogus?

The code is here:

http://hg.python.org/cpython/file/2.7/Lib/platform.py#l141

Perhaps you could open an issue on the Python bug tracker.

--
Ned Deily,
n...@acm.org

[Christian Gollwitzer]

Am 12.10.13 09:20, schrieb Ned Deily:

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.


Christian

[Christian Gollwitzer]

Am 12.10.13 09:53, schrieb Christian Gollwitzer:

> Am 12.10.13 09:20, schrieb Ned Deily:
>> In article <l3as90$5bk$1...@dont-email.me>, John Nagle <na...@animats.com>
>> wrote:
>> [...]
>>> Why is the info from "plaform.libc_ver()" so bogus?
>>
>> The code is here:
>>
>> http://hg.python.org/cpython/file/2.7/Lib/platform.py#l141
>>
>> Perhaps you could open an issue on the Python bug tracker.
>
> 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.

And it also explains why this fails:

egrep -o -a GLIBC_[0-9.]* /usr/bin/python

reports multiple matches, with the first being the lowest compatibility
version.

Christian

[Terry Reedy]

So *please* submit a patch with explanation.

--
Terry Jan Reedy

[Ian Kelly]

On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy <tjr...@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.

[Steven D'Aprano]

if sys.version < '2.5': # I think that's when ctypes was introduced
import ctypes
do_the_right_thing()
else:
do_something_bogus()


Works for me :-)



--
Steven

[Terry Reedy]

On 10/12/2013 7:43 AM, Ian Kelly wrote:
> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy <tjr...@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

[Nobody]

On Sat, 12 Oct 2013 05:43:22 -0600, Ian Kelly wrote:

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

Last I heard, there was a standing policy to avoid using ctypes from
within the standard library. The stated rationale was that ctypes is
unsafe (it allows pure Python code to crash the process) and site
administrators should be able to remove the ctypes module without breaking
any part of the standard library other than ctypes itself.

There appear to be a few exceptions to this rule, i.e. a few standard
library modules import ctypes. But they are all within try/except blocks
(so they degrade gracefully if ctypes isn't present), and are limited to
improving the handling of edge cases rather than being essential to
providing documented functionality.

[Ian Kelly]

On Sat, Oct 12, 2013 at 9:59 AM, Terry Reedy <tjr...@udel.edu> wrote:
> On 10/12/2013 7:43 AM, Ian Kelly wrote:
>>
>> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy <tjr...@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.

[John Nagle]

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

[John Nagle]

On 10/12/2013 1:28 PM, Ian Kelly wrote:
> 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.

A strange interpretation.

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

Ah, the apologist approach.

The documentation is badly written. The next line,
"Note that this function has intimate knowledge of how different libc
versions add symbols to the executable is probably only usable for
executables compiled using gcc" isn't even a sentence.

The documentation needs to be updated. Please submit a patch.

John Nagle

[Mark Lawrence]

On 13/10/2013 18:43, John Nagle wrote:
> The documentation is badly written. The next line,
> "Note that this function has intimate knowledge of how different libc
> versions add symbols to the executable is probably only usable for
> executables compiled using gcc" isn't even a sentence.
>
> The documentation needs to be updated. Please submit a patch.
>
> John Nagle
>
>

If you want it done I suggest you submit the patch.

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

[Ian Kelly]

On Sun, Oct 13, 2013 at 11:43 AM, John Nagle <na...@animats.com> wrote:
> Ah, the apologist approach.

I'm not trying to defend it. I'm saying that patching the function to
fix the issue at hand risks breaking existing code that relies upon
the function doing what the documentation says it does.

> The documentation is badly written. The next line,
> "Note that this function has intimate knowledge of how different libc
> versions add symbols to the executable is probably only usable for
> executables compiled using gcc" isn't even a sentence.
>
> The documentation needs to be updated. Please submit a patch.

You're the one pointing it out. Why don't you?