Issue 4861: fix problems with ctypes.util.find_library (original) (raw)

Created on 2009-01-06 22:02 by doko, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg79294 - (view)	Author: Matthias Klose (doko) *	Date: 2009-01-06 22:02
there are some problems with ctypes.util.find_library(), which I would like to see fixed on active branches. - find_library is not robust, if either objdump or gcc are not installed. fixed by raising an exception if the tools are not found. Is OSError the correct type for this exception? - ldconfig -p already prints the shared object name. afaics there is no need to call objdump again. - the regexp to scan the ldconfig -p output is wrong for architectures where libraries of more than one abi type are installed, e.g. having ix86 libs on a x86_64 system. Having only the library installed which doesn't match the python executable lets find_library find the wrong library. Note that the patch is only correct under the assumption that the python executable is unstalled for the "main" abi. patch attached, ok to check in?
msg79317 - (view)	Author: Thomas Heller (theller) *	Date: 2009-01-07 10:26
Matthias Klose schrieb: > there are some problems with ctypes.util.find_library(), which I would > like to see fixed on active branches. > > - find_library is not robust, if either objdump or gcc are not > installed. fixed by raising an exception if the tools are not > found. Is OSError the correct type for this exception? Sure. > - ldconfig -p already prints the shared object name. afaics there > is no need to call objdump again. > - the regexp to scan the ldconfig -p output is wrong for > architectures where libraries of more than one abi type are > installed, e.g. having ix86 libs on a x86_64 system. Having > only the library installed which doesn't match the python > executable lets find_library find the wrong library. Note that > the patch is only correct under the assumption that the python > executable is unstalled for the "main" abi. I have to trust you that this is the right approach since I don't have much experience on linux. Also I have not tested the patch. What I do not like too much in your patch is 'import platform' since that pulls in a lot of stuff. Would it be possible to replace 'platform.machine()' with 'os.uname()[4]' ?
msg79412 - (view)	Author: Matthias Klose (doko) *	Date: 2009-01-08 14:59
new version of the patch using os instead of platform, and selecting the correct library for biarch platforms, tested on ia64, sparc, s390, amd64, ppc64. unsure if there's a better way to find out if the executable is 32 or 64bit.
msg79414 - (view)	Author: Jean-Paul Calderone (exarkun) *	Date: 2009-01-08 15:02
This seems to be a partial duplicate of 3383. A suggestion on that ticket was to look for objdump in PATH and then try /usr/sbin.
msg79556 - (view)	Author: Matthias Klose (doko) *	Date: 2009-01-10 17:20
now fixed in 2.6, 2.7, 3.0 and 3.1. objdump is never installed in /sbin. I don't think we should assume a specific path for objdump. we don't do this for gcc either.
msg265230 - (view)	Author: Martin Panter (martin.panter) *	Date: 2016-05-10 08:38
FYI the OSError exceptions added here were never triggered as intended, and they are proposed to be removed as part of Issue 25751.