[Patches] [ python-Patches-641685 ] Use .dylib for shared objects on MacOS X

[noreply@sourceforge.net]

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: 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: 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