In article <CABL7CQi_jQZgHa5rL8aSsb_PEmAPTNXyUyQutgQtz=_ljux...@mail.gmail.com>, Ralf Gommers <[email protected]> wrote:
> On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <[email protected]> wrote: > > > In article <[email protected]>, > > "Russell E. Owen" <[email protected]> wrote: > > > > > In article > > > <cabl7cqjezmtswcupj0kgfjz4xc4arrwn24bi3svzjwcc2t9...@mail.gmail.com>, > > > Ralf Gommers <[email protected]> wrote: > > > > > > > On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <[email protected]> wrote: > > > > > > > > > I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit > > tests > > > > > claim the wrong version of fortran was used. I thought I knew how to > > > > > avoid that, but it's not working. > > > > > > > > > >...(elided text that suggests numpy is building using g77 even though > > I > > > > >asked for gfortran)... > > > > > > > > > > Any suggestions on how to fix this? > > > > > > > > > > > > > I assume you have g77 installed and on your PATH. If so, try moving it > > off > > > > your path. > > > > > > Yes. I would have tried that if I had known how to do it (though I'm > > > puzzled why it would be wanted since I told the installer to use > > > gfortran). > > > > > > The problem is that g77 is in /usr/bin/ and I don't have root privs on > > > this system. > > > > The explanation of why g77 is still picked up, and a possible solution: > http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826 Thank you. I assume you are referring to this answer: > You mean g77? Anyways, I think I know why you are having problems. Passing > --fcompiler to the config command only affects the Fortran compiler that is > used during configuration phase (where we compile small C programs to > determine > what your platform supports, like isnan() and the like). It does not > propagate to > the > rest of the build_ext phase where you want it. Use config_fc to set up > your > Fortran compiler for all of the phases: > > $ python setup.py config_fc --fcompiler=gnu95 build Fascinating. However, there are two things I don't understand: 1) Is my build actually broken? The ldd output for lapack_lite has no sign of libg2c.so (see quote from build instructions below). If it's just a false report from the unit then I don't need to rebuild (and there are a lot of packages built against it -- a rebuild will take much of a day). 2) This advice seems to contradict the build documentation (see below). Does this indicate a bug in the docs? In setup.py? Some other issue? I don't remember ever having this problem building numpy before. Quote from the build docs: <http://docs.scipy.org/doc/numpy/user/install.html> Choosing the fortran compiler To build with g77: python setup.py build --fcompiler=gnu To build with gfortran: python setup.py build --fcompiler=gnu95 For more information see: python setup.py build --help-fcompiler How to check the ABI of blas/lapack/atlas One relatively simple and reliable way to check for the compiler used to build a library is to use ldd on the library. If libg2c.so is a dependency, this means that g77 has been used. If libgfortran.so is a a dependency, gfortran has been used. If both are dependencies, this means both have been used, which is almost always a very bad idea. ----- ldd on my numpy/linalg/lapack_lite.so (I don't see libg2c.so): -bash-3.2$ ldd /astro/users/rowen/local/lib/python/numpy/linalg/lapack_lite.so linux-vdso.so.1 => (0x00007fff0cff0000) liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00002acadd738000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002acadde42000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00002acade096000) libm.so.6 => /lib64/libm.so.6 (0x00002acade380000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002acade604000) libc.so.6 => /lib64/libc.so.6 (0x00002acade812000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002acadeb6a000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000) _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
