Well, as stated, the fix is quite simple. And voila. Newly generated configure will say ‘yes’ or ‘’ to GFC according to your compiler. (had to re-generate autoconf.m4f with autom4te --language=autoconf --freeze --output=autoconf.m4f)
The patch would be as simple as: --- fortran.m4 2012-05-26 23:17:39.464828247 -0300 +++ fortran.m4_ 2012-06-16 03:58:07.099697178 -0300 @@ -382,6 +382,11 @@ _AC_ARG_VAR_LDFLAGS()dnl _AC_ARG_VAR_LIBS()dnl _AC_PROG_FC([$2], [$1]) +if test $ac_compiler_gnu = yes; then + GFC=yes +else + GFC= +fi AC_LANG_POP(Fortran)dnl ])# AC_PROG_FC Best regards, Fabricio From: Fabrício Zimmerer Murta Sent: Saturday, June 16, 2012 3:50 AM To: Automake List Subject: BUG: AC_PROG_FC does not define GCF when compiler is gfortran If I read http://www.gnu.org/software/autoconf/manual/autoconf.html#Specifying-Target-Triplets, I read: If using gfortran or g77 (the GNU Fortran compilers), then set the shell variable GFC to ‘yes’. If the output variable FCFLAGS was not already set in the environment, then set it to -g -02 for GNU g77 (or -O2 where g77 does not accept -g). Otherwise, set FCFLAGS to -g for all other Fortran compilers. But this is not what happens. There’s no code on fortran.m4 to fill such variable, as there’s for GCC and G77 variables. This should be simple to fix and be present on a next variable. I found this while adequating configure.ac for cross-compiling. I realised that just checking for ‘gcc’ ‘icc’ ‘gfortran’ ‘ifort’ is not enough to define the compiler, as the host might be attached to it, so I found GFC variable interesting to define for the GNU versions. I will be using ac_cv_fc_compiler_gnu for now. I hope this information helps! - fabrício
smime.p7s
Description: S/MIME cryptographic signature