After switching from Apple Python to the python.org version this is the first time I tried to build scipy. I see the same problem when building scipy trunk against numpy trunk or 0.7.x against numpy 1.3. Compilers: $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) $ gcc-4.0 --version i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) $ gfortran --version GNU Fortran (GCC) 4.2.3 (obtained from http://r.research.att.com/tools/) Python: $ python Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Below is the relevant part (I think) of the build output. The "missing required architecture x86_64 in file" complaints happen for numpy builds as well, and seem to be harmless there. Any ideas? Thanks, Ralf $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python setup.py build Warning: No configuration returned, assuming unavailable.blas_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers'] lapack_opt_info: FOUND: extra_link_args = ['-Wl,-framework', '-Wl,Accelerate'] define_macros = [('NO_ATLAS_INFO', 3)] extra_compile_args = ['-faltivec'] umfpack_info: libraries umfpack not found in /Library/Frameworks/Python.framework/Versions/2.6/lib libraries umfpack not found in /usr/local/lib libraries umfpack not found in /usr/lib /Users/rgommers/Code/numpy/numpy/distutils/system_info.py:459: UserWarning: UMFPACK sparse solver (http://www.cise.ufl.edu/research/sparse/umfpack/) not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [umfpack]) or by setting the UMFPACK environment variable. warnings.warn(self.notfounderror.__doc__) NOT AVAILABLE running build <SNIP> building 'scipy.fftpack._fftpack' extension compiling C sources C compiler: gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 creating build/temp.macosx-10.3-fat-2.6/build creating build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6 creating build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy creating build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack creating build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/src compile options: '-Iscipy/fftpack/src -Ibuild/src.macosx-10.3-fat-2.6 -I/Users/rgommers/Code/numpy/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c' gcc-4.0: scipy/fftpack/src/zrfft.c gcc-4.0: build/src.macosx-10.3-fat-2.6/scipy/fftpack/src/dct.c gcc-4.0: scipy/fftpack/src/zfftnd.c gcc-4.0: build/src.macosx-10.3-fat-2.6/fortranobject.c gcc-4.0: build/src.macosx-10.3-fat-2.6/scipy/fftpack/_fftpackmodule.c gcc-4.0: scipy/fftpack/src/drfft.c gcc-4.0: scipy/fftpack/src/zfft.c /usr/local/bin/gfortran -Wall -lgfortran -arch x86_64 build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/_fftpackmodule.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfft.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/drfft.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zrfft.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfftnd.o build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/src/dct.o build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/fortranobject.o -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64 -Lbuild/temp.macosx-10.3-fat-2.6 -ldfftpack -lfftpack -lgfortran -o build/lib.macosx-10.3-fat-2.6/scipy/fftpack/_fftpack.so ld: warning: in build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/_fftpackmodule.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfft.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/drfft.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zrfft.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfftnd.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/src/dct.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/fortranobject.o, missing required architecture x86_64 in file Undefined symbols: "_MAIN__", referenced from: _main in libgfortranbegin.a(fmain.o) ld: symbol(s) not found collect2: ld returned 1 exit status ld: warning: in build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/_fftpackmodule.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfft.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/drfft.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zrfft.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfftnd.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/src/dct.o, missing required architecture x86_64 in file ld: warning: in build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/fortranobject.o, missing required architecture x86_64 in file Undefined symbols: "_MAIN__", referenced from: _main in libgfortranbegin.a(fmain.o) ld: symbol(s) not found collect2: ld returned 1 exit status error: Command "/usr/local/bin/gfortran -Wall -lgfortran -arch x86_64 build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/_fftpackmodule.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfft.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/drfft.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zrfft.o build/temp.macosx-10.3-fat-2.6/scipy/fftpack/src/zfftnd.o build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/scipy/fftpack/src/dct.o build/temp.macosx-10.3-fat-2.6/build/src.macosx-10.3-fat-2.6/fortranobject.o -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64 -Lbuild/temp.macosx-10.3-fat-2.6 -ldfftpack -lfftpack -lgfortran -o build/lib.macosx-10.3-fat-2.6/scipy/fftpack/_fftpack.so" failed with exit status 1
Ralf Gommers wrote:
$ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
Whenever you redefine one of the CFLAGS/FFLAGS/CXXFLAGS/LDFLAGS, it *overwrites* the default value (contrary to the usual behavior of having its value appended to the default value). here, by overwriting LDFLAGS, you remove all the link options necessary to build a bundle, and the linker believes you want to build an executable (hence the missing main symbol message, and all the unresolved symbols from libpython.dylib). You can see which flags to use in the scipy paver script (note in particular that the gfortran library should be linked statically, to avoid adding a dependency on gfortran for scipy binaries - I used to run the test suite in a Mac OS X chroot check this). David
On Mon, Mar 1, 2010 at 9:50 AM, David Cournapeau <david@silveregg.co.jp>wrote:
Ralf Gommers wrote:
$ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
Whenever you redefine one of the CFLAGS/FFLAGS/CXXFLAGS/LDFLAGS, it *overwrites* the default value (contrary to the usual behavior of having its value appended to the default value).
I followed the instructions under "Obtaining and Building NumPy and SciPy on this page: http://www.scipy.org/Installing_SciPy/Mac_OS_X . There it says that the above command *extends* the build flags. So that info is wrong? Or maybe I'm still not understanding something.
here, by overwriting LDFLAGS, you remove all the link options necessary to build a bundle, and the linker believes you want to build an executable (hence the missing main symbol message, and all the unresolved symbols from libpython.dylib).
To be clear, I'm just trying to build scipy on my own machine, so I can test the numpy binary installer against it. I'm not trying to build a scipy installer. Although figuring out how to do that would be good as well. Cheers, Ralf
Ralf Gommers wrote:
On Mon, Mar 1, 2010 at 9:50 AM, David Cournapeau <david@silveregg.co.jp <mailto:david@silveregg.co.jp>> wrote:
Ralf Gommers wrote:
> $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
Whenever you redefine one of the CFLAGS/FFLAGS/CXXFLAGS/LDFLAGS, it *overwrites* the default value (contrary to the usual behavior of having its value appended to the default value).
I followed the instructions under "Obtaining and Building NumPy and SciPy on this page: http://www.scipy.org/Installing_SciPy/Mac_OS_X . There it says that the above command *extends* the build flags. So that info is wrong? Or maybe I'm still not understanding something.
Both are true :) If you build with numscons, then the flags are extended. If you build with distutils, the flags are overriden. The wiki could be made clearer there.
here, by overwriting LDFLAGS, you remove all the link options necessary to build a bundle, and the linker believes you want to build an executable (hence the missing main symbol message, and all the unresolved symbols from libpython.dylib).
To be clear, I'm just trying to build scipy on my own machine
The flag issue is a distutils issue, and happens whenever you call setup.py. You should not try to edit flags if you build with distutils, really - the overriding support implies that it should be used as last resort, and otherwise, everything should be handled within distutils. cheers, David
On Mon, Mar 1, 2010 at 11:03 AM, David Cournapeau <david@silveregg.co.jp>wrote:
Ralf Gommers wrote:
On Mon, Mar 1, 2010 at 9:50 AM, David Cournapeau <david@silveregg.co.jp <mailto:david@silveregg.co.jp>> wrote:
Ralf Gommers wrote:
> $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python
Whenever you redefine one of the CFLAGS/FFLAGS/CXXFLAGS/LDFLAGS, it *overwrites* the default value (contrary to the usual behavior of
having
its value appended to the default value).
I followed the instructions under "Obtaining and Building NumPy and SciPy on this page: http://www.scipy.org/Installing_SciPy/Mac_OS_X . There it says that the above command *extends* the build flags. So that info is wrong? Or maybe I'm still not understanding something.
Both are true :) If you build with numscons, then the flags are extended. If you build with distutils, the flags are overriden.
The wiki could be made clearer there.
When everything works for me I'll update the wiki. But first some more questions. This command: $ LDFLAGS="-lgfortran -arch x86_64" FFLAGS="-arch x86_64" python setupscons.py scons --package=scipy.linalg fails: Checking for ACCELERATE ... no Checking for ATLAS ... no Checking for MKL ... no Checking for CBLAS ... (cached) no Checking for CLAPACK ... (cached) no But without trying to extend the flags: $ python setupscons.py scons --package=scipy.linalg it works: Checking for ACCELERATE ... yes Checking for CBLAS ... yes - ACCELERATE Checking for CLAPACK ... (cached) no Checking gfortran C compatibility runtime ...-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../.. -lgfortranbegin -lgfortran Checking if gfortran needs dummy main - MAIN__. Checking gfortran name mangling - '_', '', lower-case. Checking for ACCELERATE ... yes Checking for F77 BLAS ... yes - ACCELERATE Checking for ACCELERATE ... yes Checking for F77 LAPACK ... yes - ACCELERATE Any idea what is going on here? I'm using numscons 0.12.0, last commit is 76db80c1413d0b8f73761de713797355c7ccf4c0. The extra flags are needed on SL, since if I build without them: $ python setupscons.py scons -i then the build finishes and I can import scipy, but running the test suite gives a lot of errors like this: ImportError: dlopen(/Users/rgommers/Code/scipy/_csr.so, 2): no suitable image found. Did find: /Users/rgommers/Code/scipy/_csr.so: mach-o, but wrong architecture
here, by overwriting LDFLAGS, you remove all the link options
necessary
to build a bundle, and the linker believes you want to build an executable (hence the missing main symbol message, and all the unresolved symbols from libpython.dylib).
To be clear, I'm just trying to build scipy on my own machine
The flag issue is a distutils issue, and happens whenever you call setup.py. You should not try to edit flags if you build with distutils, really - the overriding support implies that it should be used as last resort, and otherwise, everything should be handled within distutils.
So is there an easy way to build scipy on SL with distutils, or should I just stick to numscons if I get that to work?
Thanks, Ralf
participants (2)
-
David Cournapeau -
Ralf Gommers