[Numpy-discussion] trouble building numpy 1.6.1 on Scientific Linux 5

[Russell E. Owen]

In article 
<CABL7CQi_jQZgHa5rL8aSsb_PEmAPTNXyUyQutgQtz=_Ljux9hA at mail.gmail.com>,
 Ralf Gommers <ralf.gommers at googlemail.com> wrote:

> On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <rowen at uw.edu> wrote:
> 
> > In article <rowen-74BAFA.11292712122011 at news.gmane.org>,
> >  "Russell E. Owen" <rowen at uw.edu> wrote:
> >
> > > In article
> > > <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA at mail.gmail.com>,
> > >  Ralf Gommers <ralf.gommers at googlemail.com> wrote:
> > >
> > > > On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen at uw.edu> 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)