classification
Title: Compile error when building a 3-way universal framework when a 2-way universal framework is present
Type: compile error Stage: committed/rejected
Components: Macintosh Versions: Python 3.2, Python 3.1, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: prniii, ronaldoussoren
Priority: normal Keywords: patch

Created on 2009-12-10 18:43 by prniii, last changed 2010-10-20 13:41 by ronaldoussoren. This issue is now closed.

Files
File name Uploaded Description Edit
setup.py.patch ronaldoussoren, 2010-07-24 11:53 review
Messages (7)
msg96213 - (view) Author: Paul Nelson (prniii) Date: 2009-12-10 18:43
By excluding the x86_64 architecture from the supplied MacOS install, 
you are crippling the ability to build an 64-bit application that embeds 
python.  The Apple supplied universal binary includes all 3 architectures 
ppc, i386, and x86_64.  If you are going to supply a Mac build you need to 
do the same.  A 64-bit app has to link against 64-bit libraries, so the 
64-bit build IS NECESSARY.  You give no warning that you are excluding 1/3  
of the architectures from your build.  It also forces the unlucky 
downloader to circumvent the install, or rebuild from source.
msg96259 - (view) Author: Paul Nelson (prniii) Date: 2009-12-11 15:10
Once the binary (ppc, i386) binary is installed it becomes impossible to 
rebuild python from source as 3-way binary on the system, without first 
removing the 2.6.4 dual architecture 
/Library/Frameworks/Python.framework.  
It causes compile failures in _curses and _curses_panel, on x86_64.
(Leopard 10.5.7 intel)

Please distribute it as a 3-way binary. Or warn in big type that the 
current install is really only suitable for Tiger and earlier systems.  
Especially since Apple is really pushing for apps to be 64-bit as well 
as 32.

Thanks
Paul
msg96260 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-12-11 15:32
I don't agree that the current binaries are only useful for Tiger and 
earlier, the binaries work just fine on Leopard and Snow Leopard as 
well.

FWIW. I'm planning to provide a 3-way universal binary, or even just 
intel (i386, x86_64) for Python 2.7 and 3.2. That installer will only 
support OSX 10.5 or later.

BTW. I'll gladly review and patches that make it easier to compile a 3-
way univeral build without first removing the existing build. 

The reason that the current installer is not 3-way universal is that it 
is not possibly to have a 3-way universal binary that will run on 10.3.9 
or later unless you use different deployment targets for the various 
architectures and those different deployment targets cause observable 
differences in behavior because Apple fixed a number of Unix API issues 
for deployment target 10.5 (or later).
msg96261 - (view) Author: Paul Nelson (prniii) Date: 2009-12-11 15:49
I would humbly suggest that it be 3-way, until it is 10.6 (Snow Leopard) 
and above.  In our case as long as we support Leopard, we will be 
supporting all 3 architectures for our software.  

It would be appreciated if the web page indicated that the .dmg is 
currently only (ppc i386),  It would have prevented issues like ours 
where I am working on embedding python into the product which is 32 bit 
and 64 bit intel and 32-bit ppc.  And several developers unwittingly 
installed the 2.6.4 (ppc i386) on their system, and then could no longer 
build the 64-bit version of our application, since XCode tried linking 
with the new 2.6 framework even though the 2.5 Python framework was the 
one specified in the project file.
msg111462 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2010-07-24 11:53
The attached patch makes sure that os.path.join(sys.prefix, 'lib') isn't added to the link path when using a framework build.

This fixes the issue at hand in that I can then build a 3-way build of 2.7 when the default 32-bit is already installed. Without the patch _curses_panel fails to build because it tries to link to a 32-bit only library.

What I haven't done yet is check how this affects the script that builds the installer. That's the primary reason for not applying the patch at this time
msg119203 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2010-10-20 12:59
I've verified that the patch does not cause problems when building the OSX installer.

That patch should be applied, with a short comment that explains why the code block is disabled for framework builds.
msg119206 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2010-10-20 13:41
Committed the fix for 3.2 in r85744, for 2.7 in r85745 and for 3.1 in r85746

BTW. The installer does mention which architectures are supported, both in a README on the disk image and in one of the readme screens in the installer.
History
Date User Action Args
2010-10-20 13:41:34ronaldoussorensetstatus: open -> closed

messages: + msg119206
stage: needs patch -> committed/rejected
2010-10-20 12:59:36ronaldoussorensetmessages: + msg119203
versions: - Python 2.6
2010-07-24 11:53:22ronaldoussorensetkeywords: + patch
files: + setup.py.patch
messages: + msg111462

versions: + Python 3.1, Python 2.7, Python 3.2
2009-12-11 15:49:33prniiisetmessages: + msg96261
2009-12-11 15:33:38ronaldoussorensettitle: x84_64 arch Missing from 2.6.4 Mac universal binaries - Cripples building embedded 64-bit -> Compile error when building a 3-way universal framework when a 2-way universal framework is present
resolution: accepted
stage: needs patch
2009-12-11 15:32:42ronaldoussorensetmessages: + msg96260
2009-12-11 15:10:59prniiisettype: behavior -> compile error
messages: + msg96259
2009-12-10 18:43:39prniiicreate