Compiler toolchains for mixed-language projects (C++/Fortran)

[MarDiehl]

I was wondering whether the homebrew team has any recommendations for projects that use C++ and Fortran and rely on dependencies that are build with different compiler toolchains (LLVM vs GNU).

Some background: I'm part of the DAMASK team that provides the damask-grid formula/bottle. So far, all dependencies use the GNU toolchain. Recently, we started using boost, which is build on homebrew with clang++ from the LLMV toolchain. Note that Boost is mainly header-only, but some libraries are actually compiled during installation.
Now, we (in particular @eisenlohr) are not able to use homebrew for DAMASK due to

• Usage of two C++ standard libraries (boost from LLVM, other dependencies from GNU)
• Incompatible headers (ISO_Fortran_binding.h of LLVM is not what gfortran expects)

Besides concrete help for my situation, it would be interesting to know whether there is a long-term vision for the handling of different compiler toolchains:

• Migrate all bottles to LLVM. The availability of Flang makes this a realistic option even for Fortran
• Provide all bottles in two flavors, LLVM and GNU
• Keep it as it is and find solutions/workarounds when needed

[fxcoudert]

The current recommendation and Homebrew practice is to use the system compilers for C and C++ (from Apple's clang) and GNU Fortran as Fortran compiler. We do not think that Flang is production-ready yet, although we would be happy to revisit the issue in a future version, provided that it can build all of our Fortran software: we would need to switch our entire dependency tree as a coordinated move.

[MarDiehl]

My recent experience with Flang was quite positive, so the transition might not be too far away.

Can you confirm that current bottles (e.g. MPICH, hdf5) use a mixed toolchain? I assume that this works probably in most cases when combining C with Fortran, but having C++ and Fortran in the same project might complicate things.

[fxcoudert]

My recent experience with Flang was quite positive, so the transition might not be too far away.

I'm glad to hear that. The more high-quality compilers we have, the better!

The rule for the current bottles is:

• C and C++ use Apple's clang
• OpenMP is a mixture of Apple's clang unadvertised front-end support and Homebrew's libomp
• Fortran is compiled with gfortran

If you compile mixed-language C or C++/Fortran code, clang needs to be pointed to gfortran's TS 29113 header (ISO_Fortran_binding.h).

[MarDiehl]

thanks!

We indeed realized the issue with ISO_Fortran_binding.h. The remaining issue is linking the correct system libraries. Our executable is written in Fortran, so we use gfortran for linking. In a pure GNU toolchain, this only requires to explicitly add lstdc++ to link to the GNU implementation of the C++ standard library. Linking with g++ would do that automatically, similar to how gfortran knows with Fortran libraries to use. With some luck, just linking to libc++ (LLVM implementation of the C++ standard library) suffices, but I fear that gfortran pulls in a lot of system/C libraries that are not fully compatible with their LLVM counterparts.

[fxcoudert]

I fear that gfortran pulls in a lot of system/C libraries that are not fully compatible with their LLVM counterparts

Use gfortran -v to see what is passed to the linker. gfortran will typically pass as linker flags: -lgfortran -lgcc -lquadmath but nothing else is added.

You could also link with clang and simply pass -lgfortran -L/path/to/gcc/libs. Add -lgcc and -lquadmath only if you actually need them to link :)

[MarDiehl]

I have a working setup now, for the moment PETSc is installed manually (not via homebrew). I only install gcc and open-mpi (and bzip2 and libfyaml but for different reasons).

To get this to work, two hacks are needed and I was wondering whether I do something wrong or, if not, whether homebrew can be improved to get a working setup out of the box:

1. Fortran compiler wrapper: mpifort and mpif90 do not work because the gfortran executable is not found. The reason is that only gfortran-15 and the like are installed. My fix is the creation of a symlink, ln -s /opt/homebrew/bin/gfortran-15 /opt/homebrew/bin/gfortran. Would it make sense to provide a symlink to the most recent gfortran version by default?

2. I solved the issue that the LLVM compilers do not know the location of ISO_Fortran_binding.h I simply copy it to the the location of the files that include it: cp /opt/homebrew/Cellar/gcc/15.2.0/lib/gcc/current/gcc/aarch64-apple-darwin25/15/include/ISO_Fortran_binding.h src/. That works, at least if quotes instead of angle brackets in the include statements. Would it be possible to add the location of this file to the default search location, potentially with -idirafter to avoid any conflicts between GNU and LLVM headers? The possible options and their meaning are described on https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Directory-Options.html. Note that this is for GNU compilers, but LLVM aims at being compatible.

Note that I use homebrew on GitHub actions via gerlero/brew-install because I don't have a mac for testing (yet).

[fxcoudert]

In Homebrew's gcc, gfortran is installed as well as gfortran-15. A normal install of gcc should give this:

$ which gfortran
/opt/homebrew/bin/gfortran
$ which gfortran-15
/opt/homebrew/bin/gfortran-15

For the header, I would simply suggest that you pass the -I flag to the C and C++ compilers. Depending on the build system, it may be through CFLAGS or some other mechanism.

[MarDiehl]

ok, good to hear that gfortran is available by default. Then it's just an issue on GitHub Actions.

For the include path, we found --include-directory-after=$(gfortran -print-file-name=include), i.e. we can avoid to hard code a path and also make sure that GCC libraries do not take preference over LLVM libraries.

[MarDiehl]

unfortunately, our solution does not work anymore because telling Clang to use the include directory from GCC/GFortran also means that it has the includes contain the GCC C++ standard library. I would assume that files from the Clang/LLVM C++ standard library take precedence, but that is not the case.

Would it be possible to adjust the GFortran (and Flang) installation to move or copy ISO_Fortran_binding.h to a separate location and expose that with an environment variable? Otherwise, workarounds will be needed for the use of modern Fortran bindings on homebrew (also see https://github.com/orgs/Homebrew/discussions/6153). I would say that this is reasonable, because ISO_Fortran_binding.h is really a special case: It comes with the Fortran compilers but is meant for the "accompanying C compiler".

[fxcoudert]

Alternatively, can you symlink or copy the file locally in your build? Because I'm not sure where we could put this, it would be a Homebrew-specific, undocumented path, that does not appear to be a good idea.

[MarDiehl]

Sure, we have already a workaround. But since I don't want to clutter the build system with instructions like "if on homebrew and on macos do ...." that would mean that we would need to put homebrew-specific instructions in the FAQ, which is not really nice considering that people don't really read FAQs.

From the broader perspective, I would say that it would be good if homebrew supports a standard (but arguably little used) Fortran feature without a workaround. But I also agree that it is hard to find a good solution.

Another solutions that is less cumbersome to use and results in the expected behavior for a single-vendor toolchain:

1. add an additional directory to the include path of Clang with -isystem or -isystem-after.
2. Tell the Fortran compiler to place the ISO_Fortran_binding.h in that directory during installation.

Things to consider

• Possible for Clang provided by XCode?
• OK according to the security guidelines? At least files are not written in a folder that is own by a different package
• What happens if Flang and GFortran are installed simultaneously? Have two dummy directories?