[SciPy-dev] side effects of changes to fortran_libraries?

[Pearu Peterson]

Hi Eric,

On Sun, 17 Feb 2002, eric wrote:

> I just did an update and rebuild and ran into a few issues with the Fortran
> stuff.  Now that scipy_distutils requires explicit linking (which is a good
> thing), we don't get the libraries from the Fortran compiler added to the list
> of libraries needed for linking.  I had to add 'g2c' to the extension in special
> to get it to compile (and there are probably others like this).
> 
>     ext = Extension(parent_package+'special.cephes',sources,
>                     libraries = ['amos','toms','mach','g2c']
> 
> This is bad because it is compiler specific.  So, I guess the question is,
> should we add a 'fortran_libraries' to the extension so that distutils knows to
> ask the fortran compiler class what libraries are needed for linking.
> 
> Any better ideas?

Fixed in CVS. Just forgot to add complier specific libraries when the
extension needed fortran_libraries. Try now without 'g2c'.

This fix only works if libraries in Extension are really built from
fortran sources. However, the problem remains for linalg as it uses fblas
but linalg does not compile any fortran files. So, scipy_distutils thinks
that there are no fortran_libraries needed, therefore also fortran
compiler specific libraries are not needed. Currently, atlas_info includes
g2c to the libraries list but it shouldn't. As a fix, may be
fortran_libraries should also accept items with empty sources list so that
system wide fortran libraries can be specified there and when building
then fortran compiler libraries get included.

I think when adding fortran_libraries to Extension, there will be the same
issues. 

Unanswered question is how to determine if a library, say f77blas in
get_atlas_info, needs to be linked against Fortran compiler libraries?
And to which Fortran compiler libraries? In scipy_local.cfg maybe?

Pearu