[SciPy-User] Problems building SciPy on OS X due to ppc64 issues

[Ralf Gommers]

On Sat, Oct 9, 2010 at 2:14 AM, Dr. David Kirkby <david.kirkby at onetel.net>wrote:

> Numpy and SciPy are used in the Sage project. A ticket has been opened to
> update
> Numpy to 1.5.0 and SciPy to 0.8.
>
> We hit a problem with Numpy and Solaris, though the number developers have
> now
> committed a fix for that issue.
>
> However, we have an issue with people being unable to build on OS X. I
> personally do not have an OS X machine, but there's a log of a failed build
> here:
>
> http://sage.math.washington.edu/home/palmieri/misc/scipy-0.8.log
>
> For reasons I think are rather stupid, we use a script sage_fortran which
> is the
> Fortran compiler, so references below to
> /Applications/sage_builds/numpy/sage-4.6.alpha2/local/bin/sage_fortran
>
> is actually just a link to 'gfortran'
>
> It seems to resolve around the error message about two files "...have the
> same
> architectures (ppc64) and can't be in the same fat output file
>

Some googling turns up this which seems related to your issue:
http://omgili.com/mailinglist/boost-users/lists/boost/org/2E4E2E72-3D6F-41B3-BB5B-0D81145DEA59orchidseedorg.html

You are using the 10.6 SDK and gcc 4.2. In the 10.6 SDK the ppc64
architecture is not supported anymore, you want to use 10.4 or 10.5 SDK.
Since Python is built with gcc 4.0 you want to do the same if you want C++
support for ppc64 (which you'll need for scipy.sparsetools).

The above may be irrelevant for you though, since Sage is distributing
binaries for each OS X version separately, right? 10.6 doesn't install on
ppc64 machines, so no need to build that arch at all.


> See below.
>
> creating build/temp.macosx-10.6-i386-2.6/scipy/fftpack
> creating build/temp.macosx-10.6-i386-2.6/scipy/fftpack/src
> creating build/temp.macosx-10.6-i386-2.6/scipy/fftpack/src/dfftpack
> compile options:
>
> '-I/Applications/sage_builds/numpy/sage-4.6.alpha2/local/lib/python2.6/site-packages/numpy/core/include
> -c'
> sage_fortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
> lipo: /var/folders/JV/JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-//ccHZoMkv.out and
> /var/folders/JV/JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-//ccpHWmlC.out have the
> same
> architectures (ppc64) and can't be in the same fat output file
> lipo: /var/folders/JV/JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-//ccHZoMkv.out and
> /var/folders/JV/JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-//ccpHWmlC.out have the
> same
> architectures (ppc64) and can't be in the same fat output file
> error: Command
> "/Applications/sage_builds/numpy/sage-4.6.alpha2/local/bin/sage_fortran
> -Wall
> -ffixed-form -fno-second-underscore -arch ppc -arch x86_64 -arch ppc64
> -fPIC -O3
> -funroll-loops
>
> -I/Applications/sage_builds/numpy/sage-4.6.alpha2/local/lib/python2.6/site-packages/numpy/core/include
> -c -c scipy/fftpack/src/dfftpack/dcosqb.f -o
> build/temp.macosx-10.6-i386-2.6/scipy/fftpack/src/dfftpack/dcosqb.o" failed
> with
> exit status 1
> Error building scipy.
>
> Googling has thrown up a few possible ideas for how to solve this.
>
>
>     *  http://projects.scipy.org/numpy/ticket/1399
>     *  http://article.gmane.org/gmane.comp.python.scientific.devel/14564
>     *  http://article.gmane.org/gmane.comp.python.scientific.user/26314
>
> I now that
>
> http://projects.scipy.org/numpy/ticket/1399
>

This is a different issue, but that patch could have caused your problem.
But if so, the workaround in the email threads above you link to should have
resolved it. Looking at these lines of the build log:
  Fortran f77 compiler:
/Applications/sage_builds/numpy/sage-4.6.alpha2/local/bin/sage_fortran -Wall
-ffixed-form -fno-second-underscore -arch ppc -arch x86_64 -arch ppc64 -fPIC
-O3 -funroll-loops
  Fortran f90 compiler:
/Applications/sage_builds/numpy/sage-4.6.alpha2/local/bin/sage_fortran -Wall
-fno-second-underscore -arch ppc -arch x86_64 -arch ppc64 -fPIC -O3
-funroll-loops
shows that the i386 (or i686) target is missing, so it's more likely your
build script is doing something strange here.


>
> has been open 8 months, is at the highest priority, but does not seem to
> have
> been resolved yet. It is unclear if our problem is the same or not.
>

It was reopened last week, so not exactly 8 months, and should be fixed
before 1.5.1rc1 next week. Most likely by just reverting r8453.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20101009/efaf3981/attachment.html>