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.

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....)

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.

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.

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).

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.

Logged In: YES 
user_id=580910

Somehow I didn't upload the patch when I created this
thread. Here it is.

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?

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.

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!

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).

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.

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.

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.)

Logged In: YES 
user_id=33168

Jack, what should be done for this patch?

Logged In: YES 
user_id=45365

Closing this: the main part of the patch was recognizing .dylib as an 
allowed extension for shared libraries in distutils. The other part of the 
patch (using .dylib for Python extension modules in stead of .so) has 
been overtaken by real world events: Apple now lists .so as the 
extension used by "various unix packages" (read: Apache and Python:-) 
for dynamically loaded extensions.