[ python-Bugs-1486897 ] OS X framework build for python 2.5 fails, configure is odd
SourceForge.net
noreply at sourceforge.net
Tue May 23 19:44:15 CEST 2006
Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd
Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic
library at /Library/Frameworks/Python.framework/Versions/2.5/Python
where it should. The python2.5 executible does not run because it is
trying to load this dynamic library.
This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.
Also all of the extra modules (_CG extension, IDLE extra) fail to link
because their link command is -lpython2.5 which is not what it should be
for a framework build and even if it was correct for linking agianst a
framework it would fil because the framework doesn't have its library
anyway.
Finally, the configure script behaves oddly in that it works fine, but if you
change the parameters and rerun it it will fail unless you run 'make
distclean'
This is where it fails.
checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module
----------------------------------------------------------------------
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 19:44
Message:
Logged In: YES
user_id=580910
Why do you try to use --enable-profiling with a framework install? Whenever I
need such a special build I generally install a normal unix build in a
temporary location.
I know --enable-framework doesn't clean up after itself. It does work
correctly in a seperate build directory though, that way you can just dump the
build directory to clean up.
BTW. Integrating 'make frameworkinstall' into 'make install' seems to be
pretty easy, I might check in a patch later this week.
--enable-profiling crashes for me too, I don't have time to look into this at
the moment.
----------------------------------------------------------------------
Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 18:54
Message:
Logged In: YES
user_id=1346203
Sorry - it was too early in the morning here and I forgot about the
frameworkinstall....
The frameworkinstall does not quite work.
It looks like it installs everything critical and then fails on the MacPython
stuff. Specifically, it fails here:
/usr/bin/install -c -s ../../python.exe "/Library/Frameworks/
Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/
Python"
../../python.exe ./../scripts/BuildApplet.py \
--destroot "" \
--python /Library/Frameworks/Python.framework/Versions/2.5/
Resources/Python.app/Contents/MacOS/Python \
--output "/Applications/MacPython 2.5/Build Applet.app" \
./../scripts/BuildApplet.py
make[1]: *** [install_BuildApplet] Bus error
make: *** [frameworkinstallapps] Error 2
However, I can still run the python interpeter - although when I exit the
interpretor it says "mcount: gmon.out: Permission denied"
frameworkinstall does overwrite the Current symlink - but I just fixed it
manually.
Also I noticed that make clean does not remove the actual dynamic library
called 'Python' from the Python.framework directory in the build directory
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 18:26
Message:
Logged In: YES
user_id=580910
You shouldn't use make install, but make frameworkinstall. This is documented
in Mac/OSX/README.
I wouldn't mind seeing a patch that makes it possible to install a framework
using 'make install', but that's very low on my todo-list.
----------------------------------------------------------------------
Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 17:41
Message:
Logged In: YES
user_id=1346203
I checked out rev 46110 and it is almost fixed.
It builds correctly now - however the make install (or altinstall) does not copy
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but
nothing is there. If I copy it over manually then the python2.5 interpeter will
run.
The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python
The rest of my comment is more of an aside than a bug...
The equivalent symlink exists in the built version of the 2.5 framework and it
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade
from python2.4 to 2.5 then the symlink should also be updated - otherwise
when people add the linker flag -framework Python to their builds it will keep
linking against the 2.4 dynamic lib.
Also I am not sure what happened with the build log - it is fine when I
download it - but it doesn't matter now
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:13
Message:
Logged In: YES
user_id=580910
I've checked in a fix in revision 46103. Could you please test if this solves the
problems for you?
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:27
Message:
Logged In: YES
user_id=580910
I'm currently building the trunk and I'm seeing the same issue as you. The
problem is caused by the checkin at revision 45232 by Martin van Loewis. This
forces '-lpython2.5' onto the commandline for the linker when building
extensions.
I'm working on a patch that disables this feature for framework builds.
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07
Message:
Logged In: YES
user_id=580910
The configure failure in the orginal message is not a problem, that's libffi failing.
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I
know of another one, but neither have been merged into the copy that's used by
ctypes. The only effect of this is that you won't get ctypes.
Could you test again without --enable-profiling? That's one flag I've never used
and didn't test yet. BTW. the attached build log contains lots of NUL bytes,
should it or has it been corrupted along the way?
----------------------------------------------------------------------
Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13
Message:
Logged In: YES
user_id=1346203
Hi Neal,
I checked out rev 46003 (the HEAD at the time) in a clean directory and used:
./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk
Unfortunately it failed in the same way it has the same problems in that it is
linking with the flag -lpython2.5 when it should be a framework linking. I
have attached the build log from after having built it once so you only see the
linking.
However, it does appear that the issue raised in bug # 1487105 is solved. It
compiled fine on an intel mac it just has linking problems.
Also I get exactly the same problem on a G5
Chris
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25
Message:
Logged In: YES
user_id=33168
Christopher can you try with a current checkout? Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470
More information about the Python-bugs-list
mailing list