[Patches] [ python-Patches-641685 ] Use .dylib for shared objects on MacOS X
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 03 Dec 2002 10:33:32 -0800
Patches item #641685, was opened at 2002-11-21 01: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: Jack Jansen (jackjansen)
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: A.M. Kuchling (akuchling)
Date: 2002-12-03 13:33
Message:
Logged In: YES
user_id=11375
Reassigning to Jack.
(It doesn't look like find_library_file in setup.jaguar.py is actually used,
so maybe you could just delete it.)
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-11-27 08:48
Message:
Logged In: YES
user_id=11375
I've checked in my setup.py patch, and the Lib/distutils/extension.py
portion of Ronald's patch.
Is the rest of Ronald's patch OK? Should I check that in, too?
Jack reports that there's also a duplicate find_library_file in
Mac/OSX/setup.jaguar.py.
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2002-11-27 04:27
Message:
Logged In: YES
user_id=580910
I don't have checkin priviliges for the Python CVS
repository, so feel free to checkin my patches if they are
correct.
----------------------------------------------------------------------
Comment By: Jack Jansen (jackjansen)
Date: 2002-11-26 17:29
Message:
Logged In: YES
user_id=45365
I think that if we keep .so as an allowed extension for dynamically loaded modules we're okay for both 2.3a0 and 2.2.X.
Unless I misunderstand how compatibility between micro-releases is suppoosed to work, should it be forward compatible too? I.e. if 2.2.3 would create dynamic modules with .dylib they won't be useable in 2.2.2. If that is a problem then I think we should keep .so as the default and allow .dylib (for 2.2.X, for 2.3 we should do the right thing).
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-11-26 12:28
Message:
Logged In: YES
user_id=11375
Noted; updated version of the patch attached that uses
os.path.dirname. I'll check it in after testing it on the
Mac. Thanks!
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-26 11:11
Message:
Logged In: YES
user_id=21627
Andrew, that part is fine, please check it in.
There is on pitfall, though: if one of the std_dirs is a prefix of
one of the paths, and the library is found in that path, the
function will return the wrong result.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-11-26 10:37
Message:
Logged In: YES
user_id=11375
I can't pronounce on the rest of Ronald's patch, but the patch
to distutils/extension.py seems obviously correct and should be
committed in any case. Ronald, do you have CVS access or
should I check it in?
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2002-11-25 03:00
Message:
Logged In: YES
user_id=580910
Somehow I didn't upload the patch when I created this
thread. Here it is.
----------------------------------------------------------------------
Comment By: Dan Wolfe (dkwolfe)
Date: 2002-11-24 02: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 16: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 08: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 15: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 14: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