Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56726 > unrolled thread

What version of glibc is Python using?

Back to article view | Back to comp.lang.python

Contents

  What version of glibc is Python using? John Nagle <nagle@animats.com> - 2013-10-11 23:34 -0700
    Re: What version of glibc is Python using? Christian Gollwitzer <auriocus@gmx.de> - 2013-10-12 08:50 +0200
      Re: What version of glibc is Python using? John Nagle <nagle@animats.com> - 2013-10-12 00:03 -0700
        Re: What version of glibc is Python using? Ned Deily <nad@acm.org> - 2013-10-12 00:20 -0700
          Re: What version of glibc is Python using? Christian Gollwitzer <auriocus@gmx.de> - 2013-10-12 09:53 +0200
            Re: What version of glibc is Python using? Christian Gollwitzer <auriocus@gmx.de> - 2013-10-12 10:34 +0200
            Re: What version of glibc is Python using? Terry Reedy <tjreedy@udel.edu> - 2013-10-12 04:46 -0400
            Re: What version of glibc is Python using? Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-12 05:43 -0600
              Re: What version of glibc is Python using? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-12 13:08 +0000
              Re: What version of glibc is Python using? Nobody <nobody@nowhere.com> - 2013-10-12 20:02 +0100
              Re: What version of glibc is Python using? John Nagle <nagle@animats.com> - 2013-10-13 00:45 -0700
            Re: What version of glibc is Python using? Terry Reedy <tjreedy@udel.edu> - 2013-10-12 11:59 -0400
            Re: What version of glibc is Python using? Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-12 14:28 -0600
              Re: What version of glibc is Python using? John Nagle <nagle@animats.com> - 2013-10-13 10:43 -0700
                Re: What version of glibc is Python using? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-13 19:06 +0100
                Re: What version of glibc is Python using? Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-13 12:06 -0600

#56726 — What version of glibc is Python using?

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

[toc] | [next] | [standalone]

#56728

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

[toc] | [prev] | [next] | [standalone]

#56729

On 10/11/2013 11:50 PM, Christian Gollwitzer wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#56730

In article <l3as90$5bk$1@dont-email.me>, John Nagle <nagle@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,
 nad@acm.org

[toc] | [prev] | [next] | [standalone]

#56731

Am 12.10.13 09:20, schrieb Ned Deily:
> In article <l3as90$5bk$1@dont-email.me>, John Nagle <nagle@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.

glibc has a function for this:

	gnu_get_libc_version ()

which should be used.


	Christian

[toc] | [prev] | [next] | [standalone]

#56732

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 <nagle@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

[toc] | [prev] | [next] | [standalone]

#56733

On 10/12/2013 3:53 AM, Christian Gollwitzer wrote:
> Am 12.10.13 09:20, schrieb Ned Deily:
>> In article <l3as90$5bk$1@dont-email.me>, John Nagle <nagle@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.
>
> glibc has a function for this:
>
>      gnu_get_libc_version ()
>
> which should be used.

So *please* submit a patch with explanation.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#56742

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

[toc] | [prev] | [next] | [standalone]

#56743

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

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

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

[toc] | [prev] | [next] | [standalone]

#56754

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.

[toc] | [prev] | [next] | [standalone]

#56763

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

[toc] | [prev] | [next] | [standalone]

#56747

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

[toc] | [prev] | [next] | [standalone]

#56757

On Sat, Oct 12, 2013 at 9:59 AM, Terry Reedy <tjreedy@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@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.

[toc] | [prev] | [next] | [standalone]

#56773

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

[toc] | [prev] | [next] | [standalone]

#56775

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

[toc] | [prev] | [next] | [standalone]

#56776

On Sun, Oct 13, 2013 at 11:43 AM, John Nagle <nagle@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?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web