[Patches] [ python-Patches-1610795 ] BSD version of ctypes.util.find_library
SourceForge.net
noreply at sourceforge.net
Wed Dec 20 19:43:00 CET 2006
Patches item #1610795, was opened at 2006-12-07 14:29
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1610795&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin Kammerhofer (mkam)
Assigned to: Thomas Heller (theller)
Summary: BSD version of ctypes.util.find_library
Initial Comment:
The ctypes.util.find_library function for Posix systems is actually
tailored for Linux systems. While the _findlib_gcc function relies
only on the GNU compiler and may therefore work on any system with the
"gcc" command in PATH, the _findLib_ld function relies on the
/sbin/ldconfig command (originating from SunOS 4.0) which is not
standardized. The version from GNU libc differs in option syntax and
output format from other ldconfig programs around.
I therefore provide a patch that enables find_library to properly
communicate with the ldconfig program on FreeBSD systems. It has been
tested on FreeBSD 4.11 and 6.2. It probably works on other *BSD
systems too. (It works without this patch on FreeBSD, because after
getting an error from ldconfig it falls back to _findlib_gcc.)
While at it I also tidied up the Linux specific code: I'm escaping the
function argument before interpolating it into a regular expression (to
protect against nasty regexps) and removed the code for creation of a
temporary file that was not used in any way.
----------------------------------------------------------------------
>Comment By: Thomas Heller (theller)
Date: 2006-12-20 19:43
Message:
Logged In: YES
user_id=11105
Originator: NO
Unfortunately I'm unable to review or work on this patch *this year*. I
will definitely take a look in January. Sorry.
----------------------------------------------------------------------
Comment By: Martin Kammerhofer (mkam)
Date: 2006-12-12 12:28
Message:
Logged In: YES
user_id=1656067
Originator: YES
Here is the revised patch. Tested on a (virtual) OpenBSD 3.9 machine,
FreeBSD 4.11, FreeBSD 6.2 and DragonFlyBSD 1.6. Does not make assumptions
on how many version numbers are appended to a library name any more. Even
mixed length names (e.g. libfoo.so.8.9 vs. libfoo.so.10) compare in a
meaningful way. (BTW: I also tried NetBSD 2.0.2, but its ldconfig is to
different.)
File Added: ctypes-util.py.patch
----------------------------------------------------------------------
Comment By: Martin Kammerhofer (mkam)
Date: 2006-12-11 11:10
Message:
Logged In: YES
user_id=1656067
Originator: YES
Hm, I did not know that OpenBSD is still using two version numbers for
shared library.
(I conclude that from the "libc.so.39.0" in the previous followup. Btw
FreeBSD has used
a MAJOR.MINOR[.DEWEY] scheme during the ancient days of the aout
executable format.)
Unfortunately my freebsd patch has the assumption of a single version
number built in;
more specifically the
cmp(* map(lambda x: int(x.split('.')[-1]), (a, b)))
is supposed to sort based an the last dot separated field. I guess that
OpenBSD system
does not have another libc, at least none with a minor > 0. ;-)
Thomas, can you mail me the output of "ldconfig -r"? I will refine the
patch then,
doing a more general sort algorithm; i.e. sort by all trailing /(\.\d+)+/
fields. Said output from NetBSD welcome too. DragonflyBSD should be no
problem since it is a fork of FreeBSD 4.8, but what looks its sys.platform
like?
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2006-12-08 21:32
Message:
Logged In: YES
user_id=11105
Originator: NO
I have tested the patch on FreeBSD 6.0 and (after extending the check to
test for sys.platform.startswith("openbsd")) on OpenBSD 3.9 and it works
fine.
find_library("c") now returns libc.so.6 on FreeBSD 6.0, and libc.so.39.0
in OpenBSD 3.9, while it returned 'None' before on both machines.
----------------------------------------------------------------------
Comment By: David Remahl (chmod007)
Date: 2006-12-08 08:50
Message:
Logged In: YES
user_id=2135
Originator: NO
# Does this work (without the gcc fallback) on other *BSD systems too?
I don't know, but it doesn't work on Darwin (which already has a custom
method through macholib).
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2006-12-07 22:11
Message:
Logged In: YES
user_id=11105
Originator: NO
Will do (although I would appreciate review from others too; I'm not
exactly a BSD expert).
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2006-12-07 20:15
Message:
Logged In: YES
user_id=21627
Originator: NO
Thomas, can you take a look?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1610795&group_id=5470
More information about the Patches
mailing list