On 10/12/2013 4: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. >> >> >> 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
