Missing fortran compiler prevents CCTK_REAL8 from being defined.

[Steven R. Brandt]

If the fortran compiler is missing or invalid, Cactus does not create the definition for CCTK_REAL8, CCTK_REAL4, etc.

Keyword:

[Frank Löffler]

Has someone a patch for this already?

[Frank Löffler]

Changing to ET milestone

[Frank Löffler]

It works if F77/F90 are set to 'none' or it is unset. So, this problem only appears if the user did specify something as fortran compiler but that doesn't work. Thus, I think it is warrented to downgrade this ticket; please revert if you disagree.

However, the ticket itself should be left open because it is still an error.

In the case above you see in the configure output quite some warnings about things going wrong:

Unknown Linux f90 compiler 'dfadf'.
Please add appropriate information to
  /home/knarf/Cactus/lib/make/known-architectures/linux
and send the updated file to CactusMaint
We will try anyway ...

and

Determining number of fortran underscores...
Compiling test file with sdfsa -fopenmp -g -fcray-pointer -m128bit-long-double ...
Failed to compile fname_test.f
Creating null fortran name conversion routine
Compiling test file with dfadf -fopenmp -g -fcray-pointer -m128bit-long-double ...
Failed to compile fname_test.f
Creating null fortran common name conversion routine.
Fortran compilation failed ...
COMPILATION WILL FAIL WITH ANY FORTRAN SOURCE CODE

One part of the problem is close to line 1121 in lib/make/configure.in:

if test -n "$CCTK_REAL8" -a \( "x$F77" = 'xnone' -o \( "x$cctk_cv_have_fortran_real8" -a "x$cctk_cv_have_fortran_complex16" = 'xyes' \) \); then
  AC_DEFINE_UNQUOTED(CCTK_REAL8, $CCTK_REAL8)
  AC_DEFINE(HAVE_CCTK_REAL8)
fi

In short: only define CCTK_REAL8 is C did find it and if either fortran did as well or F77 is set to 'none'.

Now the question is how to best handle this case. The user specified a non-working Fortran compiler (or used a standard option list but doesn't have the compiler installed). I suggest to let configure fail at the point of

COMPILATION WILL FAIL WITH ANY FORTRAN SOURCE CODE

with hints to either correct the F77/F90 entries in the optionlist or to either not set them or set them to 'none' of indeed no Fortran compiler is needed.

The following patch implements the message, but the return value of that script isn't checked for, so a patch aborting configure at that stage would need to be either at another place or more invasive.

Index: configure.pl
===================================================================
--- configure.pl        (revision 4902)
+++ configure.pl        (working copy)
@@ -35,6 +35,9 @@
 {
   print "Fortran compilation failed ...\n";
   print "COMPILATION WILL FAIL WITH ANY FORTRAN SOURCE CODE\n";
+  print " ! Apparently a Fortran compiler was specified (F77/F90), but it does not \n".
+        " ! seem to be working. Either make sure to specify a working Fortran compiler, \n".
+        " ! do not set F77/F90, or set them to 'none'.\n\n"; 
 }

 sub test_fortran_name

[Ian Hinder]

I agree. If the user has specified a Fortran compiler in their optionlist and that compiler does not exist, this should be an immediate fatal error. It indicates either that the user has made an error in the optionlist, that the machine configuration has changed, or that the optionlist is not suitable for that system. All of these should be caught as early as possible.

The only argument I can see for this not being an error is if the user wants to use a "generic" optionlist for C thorns only on a system which doesn't have a Fortran compiler. If we really want to support this case, then we need to ensure that the entire configuration stage works with an invalid Fortran compiler, and I think this is unnecessarily complicated. The user can easily work around that by either setting F90 = none on the command line, or editing the optionlist.

[Erik Schnetter]

The suggested patch above uses the terms "F77" and "F90", but it is not clear what they mean. We should be specific and say that these are options. If F90 is set, then F77 is unused, so we should probably not mention it here. We should also mention the compiler options F90FLAGS, since these may also make a compilation fail.

We should exit with a failure return code, and check the return code in the caller, presumably configure.in, and then abort there as well.

[Frank Löffler]

Does anyone have a ready-to-test solution?

[Erik Schnetter]

I don't think this should be a release goal.

[Frank Löffler]

It shouldn't hold up the release, but it is sad that tickets like this don't receive the attention they should (including me here).

[Roland Haas]

This pull request

https://bitbucket.org/cactuscode/cactus/pull-requests/57/rhaas-check-compilers/diff

checks that the provided Fortran compiler actually works. For technical reasons (autoconf2.13 not supporting FORTRAN90 that is) it actually tests a F77 file but since we force F90 and F77 to be identical anyway this is fine.

[Roland Haas]

Ready for review.

[Roland Haas]

Unless objected I will push after 2019-06-28.

[Roland Haas]

Applied as git hash be815359 "Cactus: check that F90 compiler works" of cactus

[Roland Haas]

This contains a bug since autoconf names F77FLAGS FFLAGS. Fixed in pull request https://bitbucket.org/cactuscode/cactus/pull-requests/63/rhaas-f77flags

[Roland Haas]

Please review.

[Roland Haas]

Applied as git hash 1aa9de3f "Cactus: regenerate configure" of cactus