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
