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! -- giorgio@gilestro.tk http://www.cafelamarck.it
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 -- 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
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 -- 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
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
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
Barry Wark wrote: 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 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).
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 -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
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, 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
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. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
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
-- giorgio@gilestro.tk http://www.cafelamarck.it
participants (6)
-
Barry Wark -
Christopher Barker -
David Cournapeau -
Giorgio F. Gilestro -
Joshua Lippai -
Robert Kern