openblas: use cmake and depend on libomp

[ywwry66]

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

---

Related to #209091, #129648, #129100. Upstream has added support for buiding with libomp through OpenMathLib/OpenBLAS#5180, where one can also find multiple issues linked from downstream repositories that are caused by Homebrew's handling of OpenMP for OpenBLAS.

This change requires dependents of OpenBLAS also switched to libomp. For gromacs, cp2k and fftw, the switch seems relatively straightforward. However, I am not sure how to go about dynare. Currently, dynare is directly linked to libgomp and it also pulls in libomp through suite-sparse.

[ywwry66]

The failures on macOS 15-arm64 can be reproduced on my Sequoia macbook with the current OpenBLAS bottle, so they are not related to this PR.

1. arpack: Minitest::Assertion: Expected /reached/ to match " ** On entry to DLASCL parameter number 4 had an illegal value\n ** On entry to DLASCL parameter number 4 had an illegal value\n \n Error with _naupd, info = -9999\n Check the documentation of _naupd\n \n". (failed regression check for 3.9.1 on macos sequoia opencollab/arpack-ng#469)
2. mlpack: /opt/homebrew/include/cereal/types/tuple.hpp:98:41: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw] (Fix instances of -Wmissing-template-arg-list-after-template-kw. USCiLab/cereal#835)

There is an error I didn't see before:

• shtools: make: *** [run-fortran-tests-no-timing] Error 137 (GH Runner out of memory? Cannot reproduce locally.)

[ywwry66]

Should switching to libomp for dependents be done in this same PR or in separate PRs?

[ywwry66]

fftw's makefile does not support libomp directly, and its cmake system is not feature complete, e.g., no mpi support. Changes to cmake were not very well received upstream. So I am not sure how to proceed here. Ping @carlocab and @cho-m for suggestions.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[ywwry66]

Keep the PR open for now.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[cho-m]

Added some workarounds for dependents. Not ideal though, e.g.

• fftw will overlink to libomp. Shouldn't impact functionality and loading overhead should be minor but would be better to only have the _omp dylibs linked
• dynare needs some patching to build as Meson doesn't allow using GCC with OpenMP. And dynare cannot be built with LLVM/Clang due to OpenMP and decomposition compiler error llvm/llvm-project#33025

---

Would likely need further testing to make sure the OpenMP support is actually functional.

[cho-m]

Will need to rebase for gromacs.
Also will split out some unrelated changes to make easier to review.

[ywwry66]

Just a word of caution: the OpenBLAS upstream is considering reverting the change that has added and streamlined OpenMP customization enabled by cmake's built-in module (ref. OpenMathLib/OpenBLAS#5413). If that is merged, it will also invalidate this PR, at least in its current form.

[cho-m]

A Makefile workaround could be:

# Workaround to use OpenMP with Apple Clang
if ENV.compiler == :clang
  inreplace "Makefile.system", "+= -fopenmp", "+= -Xpreprocessor -fopenmp"
  inreplace "Makefile.install" do |s|
    s.gsub! ":= -fopenmp", ":= -Xpreprocessor -fopenmp"
    s.gsub! "+= -lgomp", "+= -L#{Formula["libomp"].opt_lib} -lomp"
  end
end

Can't comment if this functionally behaves as expected. But at least no mixed linkage

❯ brew linkage openblas
System libraries:
  /usr/lib/libSystem.B.dylib
Homebrew libraries:
  /opt/homebrew/opt/gcc/lib/gcc/current/libgfortran.5.dylib (gcc)
  /opt/homebrew/opt/gcc/lib/gcc/current/libquadmath.0.dylib (gcc)
  /opt/homebrew/opt/libomp/lib/libomp.dylib (libomp)

❯ PKG_CONFIG_PATH=/opt/homebrew/opt/openblas/lib/pkgconfig pkgconf --cflags openblas
-I/opt/homebrew/Cellar/openblas/0.3.30/include -Xpreprocessor -fopenmp

❯ PKG_CONFIG_PATH=/opt/homebrew/opt/openblas/lib/pkgconfig pkgconf --libs openblas
-L/opt/homebrew/Cellar/openblas/0.3.30/lib -lopenblas

❯ PKG_CONFIG_PATH=/opt/homebrew/opt/openblas/lib/pkgconfig pkgconf --libs --static openblas
-L/opt/homebrew/Cellar/openblas/0.3.30/lib -lopenblas -lpthread -lgfortran -lpthread -lgfortran -L/opt/homebrew/opt/libomp/lib -lomp

[cho-m]

Experimenting with Makefile alternative in

• fftw openblas: use libomp on macOS #236492

[ywwry66]

I am trying to keep the upstream cmake improvements from being reverted so hopefully we don't need the Makefile alternative.

BTW, does the arrayfire test failure on Linux X86_64 need to be addressed?

[cho-m]

BTW, does the arrayfire test failure on Linux X86_64 need to be addressed?

• already fixed arrayfire: fix test when LLVM is installed #235676

---

Also noting that I will be updating openblas test in separate PR to run cpp_thread_test to verify OpenMP is still functional:

• openblas: add test for OpenMP #236505