[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