classification
Title: fix problems with ctypes.util.find_library
Type: Stage:
Components: ctypes Versions: Python 3.0, Python 3.1, Python 2.7, Python 2.6, Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: doko Nosy List: doko, exarkun, martin.panter, theller
Priority: normal Keywords: patch

Created on 2009-01-06 22:02 by doko, last changed 2016-05-10 08:38 by martin.panter. This issue is now closed.

Files
File name Uploaded Description Edit
ctypes-findlib.diff doko, 2009-01-06 22:02 proposed patch
ctypes-findlib.diff doko, 2009-01-08 14:59 updated patch
Messages (6)
msg79294 - (view) Author: Matthias Klose (doko) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2016-05-10 08:38:42martin.pantersetnosy: + martin.panter
messages: + msg265230
2009-01-10 17:20:40dokosetstatus: open -> closed
assignee: theller -> doko
messages: + msg79556
resolution: fixed
keywords: patch, patch
2009-01-08 15:02:37exarkunsetnosy: + exarkun
messages: + msg79414
2009-01-08 14:59:08dokosetkeywords: patch, patch
files: + ctypes-findlib.diff
messages: + msg79412
2009-01-07 10:26:46thellersetmessages: + msg79317
2009-01-06 22:02:51dokocreate