On 10/12/2013 7:43 AM, 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.
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
