This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: OS X framework build for python 2.5 fails, configure is odd
Type: Stage:
Components: Build Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: nnorwitz, ronaldoussoren, vizowl
Priority: normal Keywords:

Created on 2006-05-11 21:44 by vizowl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
build.log vizowl, 2006-05-15 17:14
Messages (13)
msg28494 - (view) Author: Christopher Knox (vizowl) Date: 2006-05-11 21:44
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
msg28495 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-05-15 06:25
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.
msg28496 - (view) Author: Christopher Knox (vizowl) Date: 2006-05-15 17:13
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
msg28497 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-23 11:07
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?
msg28498 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-23 11:27
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.
msg28499 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-23 12:13
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?
msg28500 - (view) Author: Christopher Knox (vizowl) Date: 2006-05-23 15:41
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
msg28501 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-23 16:26
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.
msg28502 - (view) Author: Christopher Knox (vizowl) Date: 2006-05-23 16:54
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
msg28503 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-23 17:44
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.
msg28504 - (view) Author: Christopher Knox (vizowl) Date: 2006-05-23 18:11
Logged In: YES 
user_id=1346203

Yeah - it works fine without --enable-profiling - I forgot that you said not to 
use it. I fear I am being less than helpful today.

msg28505 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-26 13:20
Logged In: YES 
user_id=580910

I've checked in a patch that makes it possible to use 'make install' to install a 
framework. 

--enable-profiling still doesn't work and I won't look into this anytime soon ;-(
msg28506 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-06-07 21:01
Logged In: YES 
user_id=580910

I'm closing this bug and have opened a new one for the profiling issue, it seems 
to have nothing to do with frameworks. I'm also getting a crash with a plain unix 
build if I use the right libraries. See bug #1502517
History
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43347
2006-05-11 21:44:51vizowlcreate