1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

Build fails if Fortran is not available

Issue #2099 closed
Steven R. Brandt created an issue

If you use the old generic.cfg (which has "none" for both F77 and F90) and a thornlist that consists of the flesh only, Cactus will not compile. It will complain that CCTK_REAL is undefined.

Interestingly, if no definition is provided for F77 and F90 in the optionlist, then the Cactus build system assumes gfortran and compiles.

If, however, in addition to not defining F77 and F90 in the cfg, no fortran is actually present (i.e. not installed), then the CCTK_REAL issue returns.

Keyword:

Comments (19)

  3. Roland Haas
    • changed status to open
    • removed comment

    Thank you for the patch.

    This seems like an odd way to handle this. The Kranc tutorial http://kranccode.org/tutorial.html seems to suggest that at least at the time of writing that tutorial a C / C++ compiler (no Fortran) was sufficient.

    Rather than having the AC test for CCTK_REAL run with the "no-fortran-compiler" executable and then after the fact realize what was done I would rather suggest to not run the AC test at all.

    I am not sure if there is anyone still involved in Cactus who might know, but what is the reason for the existence of no-fortran-compiler ?

    I will try and see if I can find an ET release that lets me compile at least an empty thornlist with only a C and C++ compiler but no F77 or F90 compiler present (by removing gfortran from my PATH).

  4. Erik Schnetter
    • removed comment

    The reason for not requiring Fortran is that some systems do not have a Fortran compiler, and since all of the flesh and basic thorns are (were) written in C, requiring a Fortran compiler was an unnecessary requirement that would prevent people from using Cactus.

    At that time, there were many different operating systems (not just Linux, Windows, and MacOS), and may different C compilers. GCC was not necessary available on a Unix system. There was also no free Fortran 90 compiler in existence. Hence installing a Fortran compiler was a real obstacle, in particular annoying if one didn't have any Fortran code. Consequencly, using Cactus without Fortran was working out of the box, unless one used Fortran thorns.

  5. Steven R. Brandt reporter
    • removed comment

    This has been broken for a very long time, probably since 2010 at least. I encountered the problem at the very first Cactus tutorial I was in charge of. I should have made a ticket right then.

  6. Ian Hinder
    • removed comment

    The Kranc tutorial definitely did not require a Fortran compiler. I can confirm that it no longer works. I get

    COMPILING arrangements/CactusBase/Boundary/src/ScalarBoundary.c
In file included from /home/ian/Cactus/configs/kranc/bindings/include/Boundary/cctk_Arguments.h:14:0,
                 from /home/ian/Cactus/configs/kranc/bindings/include/Boundary/cctk_ScheduleFunctions.h:1,
                 from /home/ian/Cactus/configs/kranc/bindings/include/Boundary/cctk.h:6,
                 from /home/ian/Cactus/configs/kranc/build/Boundary/ScalarBoundary.c:19:
/home/ian/Cactus/src/include/cctk_Types.h:176:21: error: unknown type name 'CCTK_REAL8'
 #  define CCTK_REAL CCTK_REAL8
                     ^
/home/ian/Cactus/src/include/cGH.h:41:3: note: in expansion of macro 'CCTK_REAL'
   CCTK_REAL cctk_delta_time;

    The Kranc tutorial has a Jenkins job to automatically test it. However, since the Jenkins system moved to NCSA, there is no longer any mathematica licence available, so we cannot run the tutorial there.

    Do we understand why CCTK_REAL is not defined? Is this really linked to the absence of a Fortran compiler? Note that the Kranc tutorial doesn't use any optionlist at all. Cactus should automatically find everything it needs.

  7. Roland Haas
    • removed comment

    I ran this test

    cd repos/flesh
for i in `git branch -a | gawk -vFS=/ '/remotes\/origin\/ET_/{print $NF}'` ; do
  git checkout $i 
  cd ../.. 
  rm -rf configs/null/ 
  F90=none F77=none make null-config THORNLIST=/dev/null PROMPT=no || bash
  cd -
done

    which finds the first failure in the ET_2014_05 release. So something changed in the flesh in between that makes it fail if there is no F90 or F77 compiler.

    I think it would be better to fix that regression than to add a workaround right now.

  8. Ian Hinder
    • removed comment

    I ran git bisect to find the responsible commit. It claims it is this one: https://bitbucket.org/cactuscode/cactus/commits/e8f2db41cd59986b256d282c57557daed035d4b6

    commit e8f2db41cd59986b256d282c57557daed035d4b6
Author: Erik Schnetter <schnetter@cct.lsu.edu>
Date:   Sat Apr 19 11:01:12 2014 +0000

    Drop explicit support for Fortran 77 in Cactus

    This patch drops explicit support for Fortran 77 in Cactus. Fortran 77
    is, for all practical purposes, a subset of Fortran 90, and thus
    Fortran 77 code can be compiled by Fortran 90 compilers.

    There is currently no platform that has a Fortran 77 and no Fortran 90
    compiler, and there is no Fortran source code in Cactus that cannot be
    compiled by a Fortran 90 compiler.

    This patch removes/ignores all configuration options regarding Fortran
    77, and compiles .f77 and .F77 files with a Fortran 90 compiler. This
    simplifies the configuration stage of Cactus.
  9. Ian Hinder
    • removed comment

    For reference, git bisect was run like this:

    cd repos/flesh
cat >test_cctk_real <<EOF
#!/bin/bash

cd ../..
rm -rf configs/null
rm -f repos/flesh/log.txt

F90=none F77=none make null-config THORNLIST=/dev/null PROMPT=no >repos/flesh/log.txt 2>&1
EOF

chmod u+x test_cctk_real
git bisect start 4c1114c004274bc13ea97a917ca0223259117018 e1ab21232c9a093812275bc08ba74870b28a0f45 --
git bisect run ./test_cctk_real

    Note that the two hashes are the "bad" and "good" commits respectively. In each case, I took the commit on the master branch which was branched from to make the release branches, otherwise git bisect complains that there is no merge base being tested because one commit is not an ancestor of the other.

  10. Ian Hinder
    • removed comment

    Given the commit message, it looks like this was the commit which implemented #1725 (Disable Fortran 77 support in Cactus). That ticket contained a proposal to remove the support, and was placed in the review state, but there was no code to review. It looks like the code was committed anyway in https://bitbucket.org/cactuscode/cactus/commits/e8f2db41cd59986b256d282c57557daed035d4b6, without having been reviewed (not that I'm claiming a review would have seen the problem, but it would have made it a bit more likely...).

  13. Roland Haas
    • removed comment

    I think I may have reviewed the commit actually (or at least remember it being proposed), though I quite likely missed the check for "none" since everything else is pretty trivial changes.

  15. Roland Haas
    • changed status to open
    • removed comment

    no-fortran-compiler was introduced in

    commit c44dd46973226cb319bd9f8bd5d769164cc42ee2
Author: Erik Schnetter <schnetter@gmail.com>
Date:   Tue Apr 26 07:37:08 2016 -0400

    Cactus: Simplify handling a missing Fortran compiler at build time

    and Frank's patch seems to do exactly what used to be done in the past. I will reword the commit message to state this and amend a "Cactus:" in front of it if this alright with everyone (author will remain Frank).

  16. Ian Hinder
    • removed comment

    I confirm that I can no longer reproduce the bug on this branch. I have not reviewed the commit, but since Roland and Frank have both had eyes on it, it's probably fine to commit, unless someone else objects. Erik?

  18. Roland Haas
    • changed status to resolved
    • removed comment

    Well I'll just commit even without Erik's go ahead.

    Pushed as git commit 10fe176b "Cactus: be more careful about =~ vs ne in perl scripts" of the flesh.

  20. Log in to comment
Assignee
–
Type
bug
Priority
minor
Status
closed
Component
Cactus
Milestone
–
Version
development version
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!