On Sat, 12 Oct 2013 05:43:22 -0600, Ian Kelly wrote:
> On Sat, Oct 12, 2013 at 2:46 AM, Terry Reedy <tjre...@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
--
https://mail.python.org/mailman/listinfo/python-list
