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

 

[John Nagle]

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

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]

[...]

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.

 

[Ian Kelly]

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]

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.

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

 

[Terry Reedy]

Was this always presence and missed, or has it been added in say, the
last 10 years?

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.

 

[Nobody]

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.

 

[John Nagle]

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

 

[John Nagle]

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]

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]

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?