fftw openblas: use libomp on macOS

[cho-m]

• 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>?

---

Experimenting with Make alternative to

• openblas: use cmake and depend on libomp #219339

As CMake support may be reverted.

[fxcoudert]

If we used libomp instead of gcc, I could see the point (lower disk usage). But we can't remove GCC anyway, because of the Fortran side, so…

[cho-m]

If we used libomp instead of gcc, I could see the point (lower disk usage). But we can't remove GCC anyway, because of the Fortran side, so…

Part of issue is mixed OpenMP usage across dependency trees, e.g.

• dynare uses libgomp but has dependency on suite-sparse which uses libomp. At same time colmap & gizmo use libomp & suite-sparse
• pytorch uses libomp but has dependency on openblas which uses libgomp
• lammps, synfig, siril, votca use libomp but has dependency on fftw which uses libgomp

Depending on how code interacts, this could lead to unexpected behavior.

Changing compiler to GCC would lead to C++ issues (libstdc++ vs libc++) so only option seems to be aligning OpenMP. In this case, libomp is easier to force everything to use than libgomp.

[fxcoudert]

But I don't think everything can use libomp, in particular, the Fortran parts.

[cho-m]

But I don't think everything can use libomp, in particular, the Fortran parts.

May need to experiment with Fortran on this. There has been tests done for C/C++ parts like https://cpufun.substack.com/i/138445340/is-there-any-way-around-this

If Fortran interacts with OpenMP in a similar fashion, then it should be possible to inject libomp and have a functioning OpenMP runtime.

There is still an inconvenience where gfortran -fopenmp won't work for compiling+linking as GCC will want to use libgomp. This is where some workarounds are needed (which is possible via CMake)

[ywwry66]

But I don't think everything can use libomp, in particular, the Fortran parts.

Some evidence of Fortran working with libomp:

• conda-forge has been using gfortran + libomp. using Apple clang with USE_OPENMP=1 OpenMathLib/OpenBLAS#5169 (comment)
• A working toy example: Cflags in openblas.pc are not compatible with Apple Clang #209091 (comment). For convenience, copied here:

gfortran -fopenmp -c test.f90 -o test.o
gfortran -L/opt/homebrew/opt/libomp/lib -lomp test.o -o test

test.f90:

PROGRAM Test
USE OMP_LIB

!$OMP PARALLEL

    CALL SLEEP(10)
    PRINT *, "Hello from process: ", OMP_GET_THREAD_NUM()

!$OMP END PARALLEL

END

[cho-m]

Closing for now. Can re-open if needed based on other PR and upstream decision.