[Patches] [ python-Patches-641685 ] Use .dylib for shared objects on MacOS X
noreply@sourceforge.net
noreply@sourceforge.net
Sat, 23 Nov 2002 23:16:35 -0800
Patches item #641685, was opened at 2002-11-21 06:12
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470
Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use .dylib for shared objects on MacOS X
Initial Comment:
This patch enables python to recognize .dylib as a
valid shared library extension on MacOS X/Darwin.
Python will also use .dylib as the extension for
native-code python modules; .so files are still
recognized for backward compatibility.
The reason for writing this patch was that setup.py
failes to recognize the existince of openssl because
there is only a shared library with suffix .dylib.
----------------------------------------------------------------------
Comment By: Dan Wolfe (dkwolfe)
Date: 2002-11-24 07:16
Message:
Logged In: YES
user_id=80173
I previously assumed that OS X was capable of linking
against .so file. This turns out not to be the case (thanks
Ronald for making me a believer!) and Ronald's original
patch would have also fixed the problem. I tested both
Ronald's and akuchling patches together, along with a minor
modification to unixcompiler.py to remove the two dylib
blocks from the find_library_file function (no longer needed
with Ronald's patches) under 10.2.2, and everything works
fine in a framework and regular Unix build.
Only thing to worry about is that the modules in the
lib-dynload directory now have a .dylib suffix. The readme
should probably be updated to tell the user they need to
manually remove these files.
Also, the test_socket_ssl.py is not run unless a -u network
is made part of the test cmd line.
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2002-11-22 21:20
Message:
Logged In: YES
user_id=580910
Please keep in mind that the .so suffix is not a valid
shared-library suffix on MacOS X: The linker will not check
for 'libfoo.so' if you link with '-lfoo'. It might therefore
be prudent to look for the .dylib before looking for a .so
(if you want to look for a .so at all).
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-11-22 13:36
Message:
Logged In: YES
user_id=11375
I've tried my patch now, and with it SSL support is automatically built on MacOS X. Whether or not this fixes the bug, though,
I think this patch should be applied to cut down on some code duplication. If someone else can make a quick sanity-check on the patch in case of silly errors, I'll check it in. (Is it a bugfix candidate? Not sure, but I'm leaning toward "yes".)
I've also revised the patch to make its behaviour completely compatible
with the unpatched version of find_library_file; bug-in-waiting pointed out by Dan Wolfe.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-11-21 20:43
Message:
Logged In: YES
user_id=11375
I've attached a copy of my still-untested patch that fixes the code duplication in setup.py. I'll try to test it this evening.
----------------------------------------------------------------------
Comment By: Dan Wolfe (dkwolfe)
Date: 2002-11-21 19:19
Message:
Logged In: YES
user_id=80173
There's a problem regarding Ronald's SSL patches - they make
setup assume that every shared library is a .dylib rather
than either a .so or .dylib, which breaks compatibility....
After some late night investigation, I found that the source
of the problem is distutils. We previously had a problem
under Mac OS X where it wasn't finding the .dylib libraries
for libz and other similar .dylib libraries - both user and
system installed. Someone came up with a patch and this can
be found in /distutils/unixcompiler.py around line 278 in
the function find_library_file. Basically, it just adds
another check to look for .dylib if it can't find the .so file.
The unixcompiler.py file inherits from the ccompiler.py file
which has a stub routine for this function. For the longest
time I thought the function in unixcompiler.py was being
called and was pulling my hair out trying to figure out why
it wasn't being finding the ssl library since it only looked
for .a and .so files...
It turns out that setup.py also implements a function by the
SAME name, but with different parameters and instead of
returning a true/false to indicate whether the library
exists, it returns the pathname to the library. This
function, unfortunately, was NOT previously modify to
support dylibs and as a result only .a and .so files would
be searched for.
Below is a diff that fixes the problem simply by adding
another check for a dylib file and returning the results if
it exists.
lobo% diff -u /Users/lobo/Desktop/Python-2.2.2/setupold.py
/Users/lobo/Desktop/Python-2.2.2/setup.py
--- /Users/lobo/Desktop/Python-2.2.2/setupold.py Wed
Oct 9 17:59:16 2002
+++ /Users/lobo/Desktop/Python-2.2.2/setup.py Thu Nov 21
09:12:43 2002
@@ -44,6 +44,10 @@
filename = compiler.library_filename(libname,
lib_type='shared')
result = find_file(filename, std_dirs, paths)
if result is not None: return result
+
+ filename = compiler.library_filename(libname,
lib_type='dylib')
+ result = find_file(filename, std_dirs, paths)
+ if result is not None: return result
filename = compiler.library_filename(libname,
lib_type='static')
result = find_file(filename, std_dirs, paths)
I've minimally tested it using the normal non framework
installed and it appears to function correctly.
Enjoy.
(sorry about not uploading a patch but SF crashes IE and
Chimera doesn't allow a attachement....)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470