[issue4472] Is shared lib building broken on trunk for Mac OS X?

Roumen Petrov report at bugs.python.org
Tue Dec 30 19:00:55 CET 2008


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Ronald, 

In proposed patch we see (insert about line 740):
+    	LDLIBRARY='libpython$(VERSION).dylib'
+	BLDLIBRARY='-L. -lpython$(VERSION)'
+	RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}'


Let see comment in configure script(about line 585):
# MacOSX framework builds need more magic. LDLIBRARY is the dynamic
# library that we build, but we do not want to link against it (we
# will find it with a -framework option). For this reason there is an
# extra variable BLDLIBRARY against which Python and the extension
# modules are linked, BLDLIBRARY. This is normally the same as
# LDLIBRARY, but empty for MacOSX framework builds.


Next on line about 675 we see:
# MacOSX framework builds need more magic. LDLIBRARY is the dynamic
# library that we build, but we do not want to link against it (we
# will find it with a -framework option). For this reason there is an
# extra variable BLDLIBRARY against which Python and the extension
# modules are linked, BLDLIBRARY. This is normally the same as
# LDLIBRARY, but empty for MacOSX framework builds.
if test "$enable_framework"
then
 LDLIBRARY='$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)'
  RUNSHARED=DYLD_FRAMEWORK_PATH="`pwd`:$DYLD_FRAMEWORK_PATH"
  BLDLIBRARY=''
else
  BLDLIBRARY='$(LDLIBRARY)'
fi  

So proposed patch is not consistent with comments. Is expected shared
build to ignore framework build ?


About "SO" - as I understand python build system it is reserved for
module suffix. So there is no reason to change it.

About .dylib - I'm sure that issue can be resolved with appropriate 
update without SO to be changed by configure.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4472>
_______________________________________


More information about the Python-bugs-list mailing list