Akim wrote:
>Also, what the heck is doing this:
>
>| configure:1069: /usr/absoft/bin/f77 -E conftest.fpp
>| conftest.fpp:2:
>| yes
>| ^
>| Non-numeric character at (^) in label field [info -f g77 M LEX]
>| configure:1075: result: no
That's in _AC_PROG_F77_GNU
>in the log file? The `[info -f g77 M LEX]' seems to indicate that,
>yes, we are running g77!!! Who is Absoft? Are they selling support
>for GNU programs? In fact, the test itself reveals something
>frightening: the input is:
>
>#ifdef __GNUC__
> yes
>#endif
>
>and running `/usr/absoft/bin/f77 -E conftest.fpp' on this does produce
>the `yes' (as demonstrated by the error above). What I don't
>understand is that nevertheless, it tried to compile it! It probably
>doesn't understand `-E' the way Autoconf expects.
>
>Could you give us more information on your ``compiler''? Its
>--version for instance might say things :) :) :) Or a man page.
>
>Steven, do you know that beast?
Absoft makes proprietary Fortran compiler(s), completely distinct from g77.
(I haven't used it myself.)
What is going on here is the following:
To check if it is running g77, autoconf tries to run:
#ifdef __GNUC__
yes
#endif
through $(F77) -E.
There are five possibilities, as far as I can tell:
1) It is g77, accepts -E for preprocessing, and will succeed and output
"yes". ==> yes
2) It is not g77, but accepts -E for preprocessing, and will succeed and
output nothing (assuming it doesn't define __GNUC__). ==> no
3) It is not g77, doesn't accept -E, and gives an compile error. ==> no
4) It is not g77, accepts -E, but interprets it differently (or just gives
a warning) and tries to compile the file. It fails with a compile error,
because "yes" is not valid F77. ==> no
5) It is not g77, accepts -E, but ignores files ending with .fpp (or
perhaps interprets -E in some way that causes it to ignore the file), and
succeeds but outputs nothing. (Or not "yes", at least. Although I would
be more comfortable if we used something more like "yeswehaveg77" that
wasn't as likely to appear in random output.) ==> no
Absoft's compiler apparently falls into (4). This is fine; the test gives
the correct result: he's not using g77.
>Also, is -E an common option for Fortran? Does Fortran naturally
>supports CPP? Are there other programs to run to emulate CPP than
>`$F77 -E'?
I don't think it matters; see above.
Anyway, back to the original problem. The output from configure that was
reported was:
checking for Fortran 77 libraries... /usr/absoft/bin/f77fe -v -N20 conftest.f
FORTRAN 77 Compiler 4.5, Copyright (c) 1987-1999, Absoft Corp.
conftest.f:
Parsing MAIN :
Generating Intermediate Code : 1
/usr/absoft/bin/ibe -o conftest.s -N31 < conftest.int
as -o conftest.o conftest.s
cc conftest.o -L/usr/absoft/lib -o conftest -lfio -lf77math -lc
rm conftest.o
FLIBS =
creating ./config.status
creating Makefile
There's something seriously messed up here. The line in the configure
script is, I believe:
ac_link_output=`eval $ac_link 2>&1 | grep -v 'Driving:'`
Somehow, it is not redirecting the output properly, because the compiler
output with -v not going into ac_link_output, and is instead going to the
screen. (If it had gone to the variable, everything would have worked,
because you can see that the appropriate -L and -l flags are included in
the output).
In autoconf 2.13, the equivalent line was, I believe:
foutput=`${F77} -v -o conftest conftest.f 2>&1`
So, there's probably some subtle error with the various evals and redirects
and pipes in the new version. Surely we have a sh guru who can identify
the problem?
Steven
