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?

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]' ?

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.

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.

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.

FYI the OSError exceptions added here were never triggered as intended, and they are proposed to be removed as part of Issue 25751.