open-mpi: force build with Homebrew’s brewed GCC

[abhinavsns]

This patch makes Open MPI always compile with the Homebrew-installed GCC (e.g. gcc-11, gcc-12, etc.) rather than Apple’s system Clang. By setting ENV["CC"]/ENV["CXX"] to the brewed-GCC shims at install time, we ensure:

Stability across Xcode/Clang upgrades. Every time Apple bumps its Clang, the “fixed headers” in GCC can go out of sync (see e.g. errors in include-fixed/stdio.h), breaking MPI builds.

Consistency for downstream formula that rely on GNU Fortran (gfortran) and MPI wrappers—PETSc, Trilinos, etc.—so that they all link against the same compiler and runtime ABI.

Minimal user overhead: folks who already depend on gcc (as Open MPI does) get the correct toolchain “for free,” without extra flags or brew extract hacks.

This change preserves all existing options and defaults (no user-visible flag changes) and only affects the build environment. We bump revision to force users’ bottles to rebuild under the new compiler settings.

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[chenrui333]

Thanks @abhinavsns!

[carlocab]

I'm not sure I understand the motivation for this change.

Stability across Xcode/Clang upgrades. Every time Apple bumps its Clang, the “fixed headers” in GCC can go out of sync (see e.g. errors in include-fixed/stdio.h), breaking MPI builds.

Isn't this a reason to avoid using GCC whenever possible?

Consistency for downstream formula that rely on GNU Fortran (gfortran) and MPI wrappers—PETSc, Trilinos, etc.—so that they all link against the same compiler and runtime ABI.

Can you give concrete examples of issues for downstream formula that this change would fix?

[carlocab]

This isn't the right way to force the use of GCC -- see openblas.rb for how to do it.

[abhinavsns]

Thanks! Fixed.

[abhinavsns]

Apple’s Clang 17 disables “relaxed template-template arguments” by default. Any library that relies on that older, more permissive rule now stops at the compile stage with errors like

error: a template argument list is expected after a name prefixed by the template keyword

That pattern can shows up in slightly older versions of several widely-used scientific libraries (PETSc, Trilinos, deal.II, etc.) once they are compiled through mpicxx. GCC 12-15 still accept the code, so an Open MPI built with brewed GCC simply sidesteps the new Clang restriction and everything builds again, no extra flags or patches.

Further, mpifort is built around gfortran, which comes only from the Homebrew gcc formula. Right now we mix clang and gcc. That split toolchain can introduce subtle ABI mismatches. Building all three wrappers with the same GCC version makes the compiler stack consistent end-to-end.

The idea here is to get immunity from further Clang template-diagnostic tightenings that Apple may ship in future Xcode releases. We could also have version controlled openmpi from brew because Apple does not allow older Clang versions easily via command line.

[abhinavsns]

I see another problem with this. Apple notoriously links gcc/g++ to clang. Downstream compilations that have to specify both MPICC/MPICXX and CC/CXX will need to be extra careful in specifying the CC/CXX flag to gcc-version/g++-version. A workaround would be Homebrew installation ships alias gcc='gcc-version' & alias g++='gcc-version'