Cactus should auto-detect newer versions of GCC from MacPorts

Create issue
Issue #1471 closed
Ian Hinder created an issue

Currently, during Cactus configuration without an optionlist on Mac OS, I get

checking for gcc-mp-4.4... no
checking for gcc-mp-4.3... no
checking for gcc-mp-4.2... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes

I have gcc-mp-4.6, and 4.7 and 4.8 are also available in macports. The configure script should be updated to detect these versions.


Comments (12)

  1. Roland Haas
    • removed comment

    Does MacPorts still call its compilers like this? If so then we should also add the homebrew equivalents ie gcc-6, gc-7 etc.

  2. Steven R. Brandt
    • removed comment

    Actually, I'm wondering if we need to bother with any of these checks. While "gcc" on Mac is clang, the ET compiles and the test suite runs (apart from the memory test thorn).

  3. Roland Haas
    • removed comment

    I guess the danger that would come to my mind would be if some of macports' packages are compiled with its own gcc or g++ and need a runtime library (eg C++ STL or something similar) that is not compatible with libraries that clang uses.

    In your test code did you build some (all, a few) of the ExternalLibraries from the tarball in the ET or use them from macports (eg the ones that Ian's instructions ask to install)?

  4. Ian Hinder reporter
    • removed comment

    Steve, are you sure that the full ET can be compiled on a Mac with Apple's gcc? What does it use for Fortran compiler? It would be great to be able to compile without needing MacPorts' or HomeBrew's compilers installed, but I was never able to get this to work, and in the end gave up because I couldn't find a clean working solution better than what we currently have.

  5. Roland Haas
    • removed comment

    It will use gfortran from HomeBrew or MacPorts (the later I don't know). So you end up with a mixed compile of clang+gfortran.

    You still need HomeBrew or MacPorts.

  6. Erik Schnetter
    • removed comment

    Mixing Clang and GCC in this way leads to trouble. In particular, their OpenMP implementations are different, leading to link errors last time I checked. If linking worked, it is likely there would be segfaults at run time. You can make it work if you disable OpenMP.

    I also don't see a good reason to mix compilers this way. If you install gfortran, you already have gcc and g++ as well, so you might as well use them to simplify things.

  7. Steven R. Brandt
    • removed comment

    Sorry, I meant to reply to Ian's earlier comment and clarify.

    I checked out a Mac from CCT, installed brew, then installed gcc, g++, gfortran, etc. (all the packages we recommend) then compiled the ET with generic.cfg and ran the test suite. Everything worked except for the Memory Test thorn.

    I have not repeated this test for port as yet.

  8. Ian Hinder reporter
    • removed comment

    Do you know if it was using gcc from Homebrew, or if it was using the Apple-provided clang (named "gcc")? Regardless, if this is true, then it would simplify things for Homebrew users, if they didn't need to use a custom optionlist, and could instead use generic.cfg.

  9. Roland Haas
    • edited description
    • changed status to resolved

    As of git hash 768cb35 "Addressing roland's issues on the PR." of simfactory2 simfactory’s setup command does detect gcc-N and gcc-mp-N and prefers those over plain gcc on Darwin OS (and only there).

  10. Roland Haas

    I would rather remove tests for gcc-mp-4.X, gcc-mp-N from Cactu's configure script. If we would want this to happen in Cactus then it should go in the darwin know-architecture file and not in the main configure script. Ideally I would like to remove it altogether.

  11. Log in to comment