classification
Title: distutils makefile from python.org installer doesn't work on OS X Snow Leopard
Type: behavior Stage: resolved
Components: Distutils, Installation, macOS Versions: Python 3.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: Greg.Slodkowicz, bskaplan, loewis, ronaldoussoren, srid, tarek
Priority: normal Keywords:

Created on 2009-12-27 04:02 by bskaplan, last changed 2010-05-19 17:08 by loewis. This issue is now closed.

Messages (8)
msg96896 - (view) Author: Ben Kaplan (bskaplan) Date: 2009-12-27 04:02
Comes from this thread on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e15915df2e9cdd9/

The Makefile for distutils in the Mac binary for Python 3.1 specifies
the use of the OS X 10.4u SDK. However, XCode only includes the SDK for
the newest two versions of OS X, currently 10.5 and 10.6. This causes
build problems with gmpy on OS X Snow Leopard and the newest XCode. It
probably will also cause problems on other libraries that are compiled
using distutils but I've seen no other reports of issues. I don't know
enough about makefiles to come up with a patch that would work on all
supported versions of OS X. 

The offending code is line 118 in the Makefile, which installs itself in
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/config/Makefile.
The line is
UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk

Here's a copy of Mensanator's errors:

$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
setup.py install
running install
running build
running build_ext
building 'gmpy' extension
creating build/temp.macosx-10.3-fat-3.1
creating build/temp.macosx-10.3-fat-3.1/src
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/
MacOSX10.4u.sdk
Please check your Xcode installation
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/
opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/
include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/
gmpy.o
In file included from src/gmpy.c:206:
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:11:20: error: limits.h: No such file or directory
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:14:2: error: #error "Something's broken.  UCHAR_MAX should be
defined in limits.h."
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:18:
msg96902 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-12-27 10:48
This is happening because "./configure --enable-universalsdk" was used
in MacPorts.

In Python source, "/Mac/BuildScript/build-installer.py" can be used to
drive ./configure with another SDK (via --sdk-path) so maybe macports
itself should use it as a pre-built step.

In any case, maybe such an option could be added in configure itself. I
am adding Ronald into the loop, he'll propably know what's the best
thing to do.
msg96904 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-12-27 11:30
AFAIK This is already fixed in the repository. 

I don't have time to verify this right now, but will do so later this week 
(which is why I'm assigning the issue to myself)
msg96905 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-12-27 11:33
I forgot to mention the workaround for the 3.1 release: reinstall XCode 
and make sure that you don't do the default install, but select the 10.4u 
SDK for installation as well.

You may then run into linking issues, they only workaround for that is to 
patch the makefile: use 'gcc-4.0' instead of just 'gcc' for compiling and 
linking.
msg96909 - (view) Author: Ben Kaplan (bskaplan) Date: 2009-12-27 13:44
The issue here isn't with Macports (which doesn't do a universal build
by default). It's with the installer on python.org which is also a
universal binary.

Macports has the advantage of knowing which OS version it's being
compiled on so it should just require a patch to the portfile. If this
issue does show up on the Macports universal build, someone should file
another report with them.
msg103528 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2010-04-18 20:51
I've fixed this issue in the repository earlier today, the installer for the next 3.1 release will include that fix.
msg106052 - (view) Author: Greg Słodkowicz (Greg.Slodkowicz) Date: 2010-05-19 12:16
Doesn't breaking installation of packages on a major platform warrant a quicker release of a fix?
msg106084 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-05-19 17:08
> Doesn't breaking installation of packages on a major platform warrant a quicker release of a fix?

No, only security-related issues may warrant a change to the release
schedule.
History
Date User Action Args
2010-05-19 17:08:05loewissetmessages: + msg106084
title: distutils makefile from python.org installer doesn't work on OS X Snow Leopard -> distutils makefile from python.org installer doesn't work on OS X Snow Leopard
2010-05-19 12:16:54Greg.Slodkowiczsetnosy: + Greg.Slodkowicz
messages: + msg106052
2010-04-18 20:51:53ronaldoussorensetstatus: open -> closed
type: behavior
messages: + msg103528

resolution: fixed
stage: resolved
2009-12-27 13:45:00bskaplansetmessages: + msg96909
2009-12-27 11:33:09ronaldoussorensetmessages: + msg96905
2009-12-27 11:30:31ronaldoussorensetassignee: tarek -> ronaldoussoren
messages: + msg96904
2009-12-27 10:48:08tareksetnosy: + ronaldoussoren
messages: + msg96902
2009-12-27 06:41:27loewissetnosy: + loewis
2009-12-27 04:08:17sridsetnosy: + srid
2009-12-27 04:02:04bskaplancreate