[SciPy-user] Latest CVS seems to break Absoft 4.6
Fri, 28 Feb 2003 11:33:55 +0200 (EET)
On 27 Feb 2003, Stephen Walton wrote:
> I have previously built SciPy on both RedHat 7.3 and RedHat 8.0 systems,
> most recently in about mid January. I use Absoft 4.6, old I know but it
> works very well. The command I use is of course "python setup.py build
> build_flib --fcompiler=Absoft install".
> At some point between then and now, the SciPy build broke with this
> setup. Specifically, the f77 compiles now use the -N15 switch to the
> f77 command. This switch is not documented in my copy of Absoft, but
> tests indicate that it results in a double underscore being appended to
> all external names. When I try to start scipy after a new build, it
> complains it cannot find cdftnc_ (one underscore). "nm cdftnc.o" shows
> the name in that file to be cdftnc__ (two underscores).
The two underscores are surprising. I recently tested scipy_distutils/f2py
with Absoft 8.0 compiler and the -N15 switch approach worked properly.
Update scipy_distutils and try again. See absoft_fortran_compiler class
in scipy_distutils/command/build_flib.py for fine tuning Absoft compiler
options if necessary.
> My not-so-educated guess is that the new switch was an effort to make
> Absoft more compatible with g77. g77 appends a double underscore only
> to names with embedded underscores, a single underscore otherwise.
> (Why?) Absoft tech support confirmed that version 4.6 cannot emulate
> this, though version 6.0 has a '-g77' switch which mangles external
> names in the same way g77 does.
Actually, scipy_distutils and f2py aim not to be compatible with g77 in
this case. Instead, the target is to be compatible with an
"average" compiler in the sense that f2py generated C codes that call
Fortran remain the same and the differences between C-to-Fortran symbol
mapping among different compilers are resolved in the level of Fortran
Yhe average Fortran compiler is expected to map any Fortran subroutine
* to lower case
* and with ending *single* underscore
as they appear in object files.
So far I have found that most Fortran compilers have switches to
support such a rule but not always the g77 mapping rule.
> These problems are why I had to build fftw from source, btw.
Hmm, scipy does not use fftw Fortran interface, so the problems must
be due to something else. See scipy/fftpack/NOTES.txt about
scipy expectations on fftw library.