[SciPy-user] Tiger and scipy

Bob Ippolito bob at redivi.com
Wed Jun 22 21:46:21 CDT 2005


On Jun 22, 2005, at 3:53 AM, Robert Kern wrote:

> Brian Granger wrote:
>
>> Hello all,
>> I wanted to see what the status of scipy on Mac OS X, 10.4 was.   
>> I  just installed the CVS version of scipy on Tiger, but I had to  
>> use  gcc 3.3 (sudo gcc_select 3.3).  I got the same error that  
>> others have  seen when I used gcc4.0.  Any word on how to resolve  
>> this problem  with gcc4.0?
>>
>
> I gave up since many other non-Scipy things didn't compile with  
> gcc4.0. I don't know if anyone is seeing gcc4.0 problems on other  
> systems.

Yeah, they are.

>> Also, I have been playing with the bdist_mpkg command that comes  
>> with  py2app (from the PyObjC project).  This makes it nearly  
>> trivial to  build a double clickable Mac installer for scipy.  Has  
>> anyone else  done this yet?
>>
>
> Have I *ever*!
>
> http://download.enthought.com/MacEnthon/ReadMe.html
> http://download.enthought.com/MacEnthon/MacEnthon-0.1.dmg
>
> I probably won't update this until I get my build environment set  
> up on my Panther machine so that I can create packages compatible  
> with both Tiger and Panther.

In theory you can compile Panther.. or even Jaguar.. compatible stuff  
on Tiger if you try hard enough.  Something like this is enough to  
convince py2app and distutils to compile Jaguar compatible stuff on  
Python 2.3 (though I needed to patch distutils to use LDSHARED  
correctly):

import os
# There's a deps/Python.framework which was built on 10.2.  Since I  
don't have it
# installed in the correct place, I need to set DYLD_FRAMEWORK_PATH  
in order
# to run it correctly.  This setup.py must be run with the target  
Python.
if os.path.abspath('deps') not in os.environ.get 
('DYLD_FRAMEWORK_PATH', ''):
     raise RuntimeError, 'This is the wrong Python'

# Try and compile in a 10.2 compatible manner
os.environ['CC'] = '/usr/bin/gcc-3.3'
deps = os.path.abspath('deps').replace(' ', '\\ ')
# I had to patch distutils in order for it to pick up LDSHARED.   
Python 2.4 doesn't have this problem.
# This is only necessary because Python.framework isn't in the  
expected place.
os.environ['LDSHARED'] = '/usr/bin/gcc-3.3 -Wl,-x -Wl,-F%s -bundle - 
framework Python' % (deps,)
os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.2'
JAGUAR_SDK = '/Developer/SDKs/MacOSX10.2.8.sdk'
if os.path.exists(JAGUAR_SDK):
     # This tells Apple GCC (anything before 4.0, anyway) to use the  
SDKs.
     os.environ['NEXT_ROOT'] = JAGUAR_SDK
     # These are for py2app's macholib.  Should fix py2app to use  
NEXT_ROOT instead of this ugly hack.
     # You probably shouldn't use this.
     os.environ['DYLD_LIBRARY_PATH'] = JAGUAR_SDK + '/usr/lib' + ':'  
+ JAGUAR_SDK + '/usr/lib/system'
     os.environ['DYLD_FRAMEWORK_PATH'] += ':' + JAGUAR_SDK + '/System/ 
Library/Frameworks'

Composed-in-mail, the equivalent for Panther compatibility would be:

# Try and compile in a 10.2 compatible manner
os.environ['CC'] = '/usr/bin/gcc-3.3'
os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3'
PANTHER_SDK = '/Developer/SDKs/MacOSX10.3.9.sdk'
if os.path.exists(PANTHER_SDK):
     os.environ['NEXT_ROOT'] = PANTHER_SDK

A more general solution would probably be this instead (again  
composed-in-mail):

#!/bin/sh
#
# sdkenv-macosx10.3
#
export MACOSX_DEPLOYMENT_TARGET=10.3
export NEXT_ROOT=/Developer/SDKs/MacOSX10.3.9.sdk
export CC=/usr/bin/gcc-3.3
# I guess a few more things might need to be set for C++, etc.
# but I'm not familiar with those env vars
$@

Then you would do:

sdkenv-macosx10.3 bdist_mpkg

... or even

sdkenv-macosx10.3 sh -c './configure && make'

-bob



More information about the SciPy-user mailing list