[SciPy-user] How to tell scipy setup that I have a INTEL fortran ATLAS/BLAS/LAPACK instead of g77

[David Cournapeau]

Berthold Höllmann wrote:
> Sorry for taking so long for the answer.
>
No problem.
>
>
> I am aware of some of the problems when mixing object files from
> different compiler brands.
It is not different brand, it is different version. Intel compiler on 
linux would have no chance of success if it was not compatible with 
gcc.  C being a relatively non moving target, extremely used, and "not 
difficult", there is an clear ABI for C, even on linux; that's the only 
language which did not have ABI incompatibilities between gcc 3 and 4 
(of fortran, C++ and C). recent ifort is only compatible with gcc 4, 
that is gfortran for fortran.

You cannot mix g77 and gfortran at all without huge pain, and thus, you 
cannot mix ifort and g77 (but you can mix gfortran and ifort).
>  Numpy is compiled using Intel Fortran
> compiler as well as scipy. The affected code is pure C code. The
> superLU code somewhere seems to use a wrapper to call BLAS routines
> like "DTRSV" from C. These wrapper routines seem to include ATLAS
> header files that define mappings from the routine name to some ATLAS
> wrapper routine name. This ATLAS wrapper name depends on the FORTRAN
> compiler that ATLAS is build for. The ATLAS header files use defines
> like "Add_" and "Add__" to distinguish between different FORTRAN
> compiler naming conventions. When compiling "superLU" from scipy
> "Add__" seems to used(some kind of default I guess), whereas "Add_"
> would be right for INTEL Fortran.
Yes, I understand the problem. g77 appends two underscore to function 
names with an underscore in the original name, that is foobar will be 
foobar_, and foo_bar will be foo_bar__. gfortran (and fortran compiler) 
do not differentiate: foobar becomes foobar_, foo_bar becomes foo_bar_.

But this is only the tip of the iceberg, which is what I wanted to say 
in my previous email. In particular, the way to pass arguments between C 
and Fortran is different in g77 and gfortran. It is different, non 
compatible (pass by value vs pass by reference, for some data type - 
COMPLEX type - for example). So even if you managed to solve the 
mangling issue, you would still have problems. IOW, g77 and gfortran 
does NOT have the same ABI, and it is impossible to make them compatible 
without recompiling. And even if you wanted to recompile, it is not 
advised: man gfortran, section -ff2c says:

"""
 -ff2c
           Generate code designed to be compatible with code generated 
by g77 and f2c.

           The calling conventions used by g77 (originally implemented 
in f2c) require functions that return type default "REAL" to actually 
return the C type "double", and functions that return type "COMPLEX" to 
return the values via an extra argument in the calling sequence that 
points to where to store the return value.  Under the  default GNU 
calling conventions, such functions simply return their results as they 
would in GNU C---default "REAL" functions return the C type "float", and 
"COMPLEX" functions return the GNU C type "complex".  Additionally, this 
option implies the -fsecond-underscore option, unless 
-fno-second-underscore is explicitly requested.

           This does not affect the generation of code that interfaces 
with the libgfortran library.

           Caution: It is not a good idea to mix Fortran code compiled 
with -ff2c with code compiled with the default -fno-f2c calling 
conventions as, calling "COMPLEX" or default "REAL" functions between 
program parts which were compiled with different calling conventions 
will break at execution time.

           Caution: This will break code which passes intrinsic 
functions of type default "REAL" or "COMPLEX" as actual arguments, as 
the library implementations use the -fno-f2c calling conventions.
"""

Actually, it is a good thing to have different name mangling, because if 
the name mangling was the same between g77 and gfortran, instead having 
people complaining of missing symbols (easy to spot and solve), we would 
have people complaining about data corruption, segmentation fault and 
the likes.

So in your case, the solution is to use compatible fortran compilers for 
numpy/scipy and the fortran libraries you are using. Both ifort or 
gfortran are fine if you are using atlas compiled with ifort.

cheers,

David