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.

[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

[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.

[dimpase]

is it still being worked on?

[cho-m]

Will note that one problem with change is pkg-config file is it in an odd half-way state

Libs: -L${libdir} -l${libnameprefix}openblas${libnamesuffix}${libsuffix} 
Cflags: -I${includedir} -Xclang -fopenmp 

This won't work as is with libomp unless user provides the missing arguments like the above line whereas GCC worked with just the pkg-config output.

Similarly, installed CMake config file may not behave as expected (as OpenMP_Fortran will link libgomp without some extra hacks):

set_target_properties(OpenBLAS::OpenBLAS PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/openblas"
  INTERFACE_LINK_LIBRARIES "m;OpenMP::OpenMP_C;OpenMP::OpenMP_Fortran"
)

However, users are more likely to use FindBLAS and FindOpenMP so may not see issue with OpenBLASConfig.cmake

[cho-m]

is it still being worked on?

We first need confirmation that upstream won't revert CMake changes.

Afterward will need to decide if the odd quirks this can introduce are worth the change.

[cho-m]

Adding comment here to make more obvious that this PR is stalled until upstream decision:

• CMake - OpenMP Check fail with NVHPC OpenMathLib/OpenBLAS#5412
• Revert "CMake: Pass OpenMP compiler and linker flags through CMake targets" OpenMathLib/OpenBLAS#5413
• CMake: Demote the OpenMP mixed linkage check to NOTICE OpenMathLib/OpenBLAS#5434