Re: What version of glibc is Python using?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On Sun, Oct 13, 2013 at 11:43 AM, John Nagle 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? -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On 10/12/2013 4:43 AM, Ian Kelly wrote:
> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy 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
--
https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On Sat, Oct 12, 2013 at 9:59 AM, Terry Reedy wrote: > On 10/12/2013 7:43 AM, Ian Kelly wrote: >> >> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On 10/12/2013 7:43 AM, Ian Kelly wrote: On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On Sat, 12 Oct 2013 05:43:22 -0600, Ian Kelly wrote: > On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
On 10/12/2013 3:53 AM, Christian Gollwitzer wrote: Am 12.10.13 09:20, schrieb Ned Deily: In article , John Nagle 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
Am 12.10.13 09:53, schrieb Christian Gollwitzer: Am 12.10.13 09:20, schrieb Ned Deily: In article , John Nagle 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
Am 12.10.13 09:20, schrieb Ned Deily: In article , John Nagle 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
In article , John Nagle 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
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:
.
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: What version of glibc is Python using?
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
--
https://mail.python.org/mailman/listinfo/python-list
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
--
https://mail.python.org/mailman/listinfo/python-list
