scipy binary for macosx tiger on ppc
Hi guys, does anyone of you happen to have sitting somewhere a DMG of a recent version of SciPy compiled for MacOSX 10.4? The SciPy webpage does not carry official releases and it is sending me to the Scipy Superpack by Chris Fonnesbeck but that superpack seems to be for intel cpu only. I didn't think making SciPy working in mac would have been such a pain in the bum. Linux and Win worked without problem but mac is driving me crazy (yes, compiling is a problem too.) Thanks!
It's actually pretty simple to compile it yourself once you've installed the latest Xcode from http://developer.apple.com and X11 from the OS X Tiger install disc. The instructions on Scipy's official OS X installation page ( http://scipy.org/Installing_SciPy/Mac_OS_X ) are great for that. That said, it is true that the Scipy Superpack is now Intel-only. You should probably email the guy and ask him to make older versions of the superpack available, or at least the last PPC one he made. Best of luck.
Josh
On Nov 29, 2007 1:54 PM, Giorgio F. Gilestro giorgio@gilestro.tk wrote:
Hi guys, does anyone of you happen to have sitting somewhere a DMG of a recent version of SciPy compiled for MacOSX 10.4? The SciPy webpage does not carry official releases and it is sending me to the Scipy Superpack by Chris Fonnesbeck but that superpack seems to be for intel cpu only. I didn't think making SciPy working in mac would have been such a pain in the bum. Linux and Win worked without problem but mac is driving me crazy (yes, compiling is a problem too.) Thanks!
-- giorgio@gilestro.tk http://www.cafelamarck.it
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Joshua Lippai wrote:
You should probably email the guy and ask him to make older versions of the superpack available, or at least the last PPC one he made. Best of luck.
Even better would be Universal (fat) binaries -- I'm pretty sure this is now possible, but haven't figured it out myself yet.
-Chris
On Nov 29, 2007 3:21 PM, Christopher Barker Chris.Barker@noaa.gov wrote:
Joshua Lippai wrote:
You should probably email the guy and ask him to make older versions of the superpack available, or at least the last PPC one he made. Best of luck.
Even better would be Universal (fat) binaries -- I'm pretty sure this is now possible, but haven't figured it out myself yet.
-Chris
-- Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Chris Fonnesbeck used to distribute both PowerPC and Intel binaries, but he can't compile them for PowerPC at all anymore because he no longer has access to a PowerPC machine. That's why now the site's manager is only distributing Intel binaries; Universal builds won't be possible for anything he does from the present time forward. Someone else would have to compile on the PPC side for him.
Josh
Joshua Lippai wrote:
Chris Fonnesbeck used to distribute both PowerPC and Intel binaries, but he can't compile them for PowerPC at all anymore because he no longer has access to a PowerPC machine.
You can build fat binaries with a single machine -- either one. Whether Chris wants to spend his time figuring all that out is up to him, but it's not a hardware limitation.
-Chris
Using the gfortran from http://r.research.att.com/tools/, it's trivial to build a universal build from source. The instructions on scipy.org won't lead you astray.
I will ask around at work. Perhaps we can start building universal scipy builds for distribution. Can anyone from the scipy devs email me off list if you'd like to pursue this?... triggering a build automatically from SVN commits or such would be good.
Barry
On Nov 29, 2007 3:43 PM, Christopher Barker Chris.Barker@noaa.gov wrote:
Joshua Lippai wrote:
Chris Fonnesbeck used to distribute both PowerPC and Intel binaries, but he can't compile them for PowerPC at all anymore because he no longer has access to a PowerPC machine.
You can build fat binaries with a single machine -- either one. Whether Chris wants to spend his time figuring all that out is up to him, but it's not a hardware limitation.
-Chris
-- Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Barry Wark wrote:
Using the gfortran from http://r.research.att.com/tools/, it's trivial to build a universal build from source. The instructions on scipy.org won't lead you astray.
I will ask around at work. Perhaps we can start building universal scipy builds for distribution. Can anyone from the scipy devs email me off list if you'd like to pursue this?... triggering a build automatically from SVN commits or such would be good.
That would be cool, but where to compile the binary ? scipy does not have build farm. Having a 100 % automatic way to build a binary would certainly be a step in this direction, though. There is also the need to test the compiled binary, which is not trivial with fat binaries. To sum up: - we need at least one x86 mac os X machine to build/test (I don't know if you can test python softwares through rosetta: I have only experience testing pure C softwares built as fat binaries) - we need a way to automate the build entirely - we need a way to automate the packaging (distutils can do only part of it or all of it ? Building a basic .pkg inside a dmg is not hard from the command line, but I don't know how it scales for non trivial packages).
cheers,
David
On 11/29/07, David Cournapeau david@ar.media.kyoto-u.ac.jp wrote:
Barry Wark wrote:
Using the gfortran from http://r.research.att.com/tools/, it's trivial to build a universal build from source. The instructions on scipy.org won't lead you astray.
I will ask around at work. Perhaps we can start building universal scipy builds for distribution. Can anyone from the scipy devs email me off list if you'd like to pursue this?... triggering a build automatically from SVN commits or such would be good.
That would be cool, but where to compile the binary ? scipy does not have build farm. Having a 100 % automatic way to build a binary would certainly be a step in this direction, though. There is also the need to test the compiled binary, which is not trivial with fat binaries. To sum up: - we need at least one x86 mac os X machine to build/test (I don't know if you can test python softwares through rosetta: I have only experience testing pure C softwares built as fat binaries)
One of our machines (OSX Intel) is already the buildbot slave for the numpy buildbot. I think I can get us OK'd to build scipy on there as well. We generate our own scipy builds so it shouldn't be too big a problem. Unless there's an automated system, I'd prefer to to just release builds.
Some remaining issues: - which SDK to build against. Leopard ships with a Python build against the 10.5 SDK. It would be much easier, at least initially, for us to produce binaries against the Leopard Python 2.5. - how to deal with library dependencies such as fftw2. We currently use MacPorts but I suppose it needs to be compiled statically or do we just require that users install MacPort's fftw2?
- we need a way to automate the build entirely
It seems like scipy needs a buildbot.
- we need a way to automate the packaging (distutils can do onlypart of it or all of it ? Building a basic .pkg inside a dmg is not hard from the command line, but I don't know how it scales for non trivial packages).
It's relatively easy to build a single pkg for the entire scipy distribution (that's what we do now) and put that on a DMG (as you said). When scipy becomes a less monolithic package (i.e. using setuptools namespace packages), we can create a pkg for each package and a mpkg combining them all.
~barry
Barry Wark wrote:
Some remaining issues:
- which SDK to build against. Leopard ships with a Python build
against the 10.5 SDK. It would be much easier, at least initially, for us to produce binaries against the Leopard Python 2.5.
I would prefer that we use the Python binary from www.python.org. That should work on 10.3.9+.
- how to deal with library dependencies such as fftw2. We currently
use MacPorts but I suppose it needs to be compiled statically or do we just require that users install MacPort's fftw2?
"Official" binaries intended for distribution from scipy.org or scipy.sf.net should not be linked against FFTW or UMFPACK since they are GPLed.
The real problem is the Fortran runtime. It is possible to link against the Fortran runtime libraries statically so as to avoid needing the user to also install a Fortran compiler just to run scipy. Use the gfortran compiler built for R's use (and do not use the one from hpc.sf.net):
http://r.research.att.com/tools/
Basically, copy the libgfortran.a library to a separate location, say ~/staticlibs/. Then do the following:
$ export LDFLAGS="-undefined dynamic_lookup -bundle -arch i386 -arch ppc -Wl,-search_paths_first" $ python setup.py config_fc --fcompiler=gnu95 --arch="-arch i386 -arch ppc" build_ext -L ~/staticlibs/ build
On 11/30/07, Robert Kern robert.kern@gmail.com wrote:
Barry Wark wrote:
Some remaining issues:
- which SDK to build against. Leopard ships with a Python build
against the 10.5 SDK. It would be much easier, at least initially, for us to produce binaries against the Leopard Python 2.5.
I would prefer that we use the Python binary from www.python.org. That should work on 10.3.9+.
OK.
- how to deal with library dependencies such as fftw2. We currently
use MacPorts but I suppose it needs to be compiled statically or do we just require that users install MacPort's fftw2?
"Official" binaries intended for distribution from scipy.org or scipy.sf.net should not be linked against FFTW or UMFPACK since they are GPLed.
Got it.
The real problem is the Fortran runtime. It is possible to link against the Fortran runtime libraries statically so as to avoid needing the user to also install a Fortran compiler just to run scipy. Use the gfortran compiler built for R's use (and do not use the one from hpc.sf.net):
http://r.research.att.com/tools/
Basically, copy the libgfortran.a library to a separate location, say ~/staticlibs/. Then do the following:
$ export LDFLAGS="-undefined dynamic_lookup -bundle -arch i386 -arch ppc -Wl,-search_paths_first" $ python setup.py config_fc --fcompiler=gnu95 --arch="-arch i386 -arch ppc" build_ext -L ~/staticlibs/ build
Thanks. I'll give it a try.
Robert Kern wrote:
I would prefer that we use the Python binary from www.python.org. That should work on 10.3.9+.
+1 -- there have always been enough issue with Apple;'s python that it's best to just use another version -- one binary for > 10.3.9 is the way to go.
"Official" binaries intended for distribution from scipy.org or scipy.sf.net should not be linked against FFTW or UMFPACK since they are GPLed.
Does that apply to binaries put up on pythonmac.org? It would be nice to have a "complete" version somewhere standard.
The real problem is the Fortran runtime. It is possible to link against the Fortran runtime libraries statically so as to avoid needing the user to also install a Fortran compiler just to run scipy.
That would be great, too.
-Chris
Christopher Barker wrote:
Robert Kern wrote:
"Official" binaries intended for distribution from scipy.org or scipy.sf.net should not be linked against FFTW or UMFPACK since they are GPLed.
Does that apply to binaries put up on pythonmac.org? It would be nice to have a "complete" version somewhere standard.
I would argue "yes, it does apply to pythonmac.org, too." scipy is a BSD-licensed package. Putting GPLed components into the binaries which are distributed at "standard" locations like our website, PyPI, or pythonmac.org confuses that picture. I would be mollified if the download link had an explanation attached, but unfortunately, pythonmac.org/packages does not have any space for that.
Even just a build of the last stable version will do it. Most people (especially those who don't want to go through the hassle of compiling) are going to be perfectly happy with a binary of the latest release.
Thanks!
Barry Wark wrote:
Using the gfortran from http://r.research.att.com/tools/, it's trivial to build a universal build from source. The instructions on scipy.org won't lead you astray.
I will ask around at work. Perhaps we can start building universal scipy builds for distribution. Can anyone from the scipy devs email me off list if you'd like to pursue this?... triggering a build automatically from SVN commits or such would be good.
Barry
On Nov 29, 2007 3:43 PM, Christopher Barker Chris.Barker@noaa.gov wrote:
Joshua Lippai wrote:
Chris Fonnesbeck used to distribute both PowerPC and Intel binaries, but he can't compile them for PowerPC at all anymore because he no longer has access to a PowerPC machine.
You can build fat binaries with a single machine -- either one. Whether Chris wants to spend his time figuring all that out is up to him, but it's not a hardware limitation.
-Chris
-- Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi Josh, you're right I should probably email the guy directly. I eventually managed to compile it installing the latest xcode, the latest cctool to fix the __dso_handle bug, the gfortran and a couple of other things. It took me an entire afternoon and now I don't have errors on the the scipy.test (but I still have failures :( ) Now I just have to figure out why mac version of matplotlib does not seem to have matplotlib.dates and where did drange go! Thanks
Joshua Lippai wrote:
It's actually pretty simple to compile it yourself once you've installed the latest Xcode from http://developer.apple.com and X11 from the OS X Tiger install disc. The instructions on Scipy's official OS X installation page ( http://scipy.org/Installing_SciPy/Mac_OS_X ) are great for that. That said, it is true that the Scipy Superpack is now Intel-only. You should probably email the guy and ask him to make older versions of the superpack available, or at least the last PPC one he made. Best of luck.
Josh
On Nov 29, 2007 1:54 PM, Giorgio F. Gilestro giorgio@gilestro.tk wrote:
Hi guys, does anyone of you happen to have sitting somewhere a DMG of a recent version of SciPy compiled for MacOSX 10.4? The SciPy webpage does not carry official releases and it is sending me to the Scipy Superpack by Chris Fonnesbeck but that superpack seems to be for intel cpu only. I didn't think making SciPy working in mac would have been such a pain in the bum. Linux and Win worked without problem but mac is driving me crazy (yes, compiling is a problem too.) Thanks!
-- giorgio@gilestro.tk http://www.cafelamarck.it
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (6)
-
Barry Wark -
Christopher Barker -
David Cournapeau -
Giorgio F. Gilestro -
Joshua Lippai -
Robert Kern