Cflags in openblas.pc are not compatible with Apple Clang #209091
Comments
|
Homebrew only runs |
|
This is probably a consequence of our using GCC to build on macOS. Using |
|
Upstream doesn't seem to be aware of a possibility to use I tried building the current git version of openblas with just I also tried to remove |
You need to enable OpenMP for a comparable build with: export USE_OPENMP=1 |
this leads to an error as above in such a configuration, almost immediately. EDIT2. I was slightly sloppy again. Now, with checkout of 0.3.29 (or with today's main), I get |
cho-m
changed the title
|
another option might be to have openblas linked to libomp, not libgomp. |
This actually appears doable, except that it's linking to both of them, Would you be interested in a PR switching this build to such a setup? |
|
I don't think we want to link to both |
|
Python people deal with multiple libomp's in one application on a regular basis. Perhaps @rgommers can comment on this. I also don't know whether there is any C OpenMP in openblas. |
This is correct, it's a recipe for major trouble.
The only reason for this is that wheels uploaded to PyPI cannot depend on a common shared library, and aren't built as a coherent stack. To make it work at all, extensive symbol mangling machinery is used. The end result is lower performance without any real upside, because you have two OpenMP runtimes that don't know about each other and hence won't manage resources as well as a single runtime could in multithreading or multiprocessing use cases. |
|
Does this mean that merely correcting flags acceptable by clang (by adding |
For In my opinion, there is no ideal solution for now. Two ways that can possibly improve the current situation is: 1. |
I doubt Apple will ship their own build of |
So this does work with gfortan and Apple clang, right? |
|
I would consider this issue an unsupported use case as pkg-config isn't flexible enough to allow multiple toolchains here. Can wait for other maintainer responses but likely will be closed as "not planned". Upstream seems to have made similar decision. As previously mentioned, it isn't possible to create a single pkg-config file that works across GCC and Clang when using OpenMP. The instant you add flags for Apple Clang it will break GCC (and negatively impact LLVM Clang which natively supports Similar situation for flags needed by GCC and LLVM Clang as When working in a build system, it will often require fighting with the defaults like overriding CMake's Additionally, switching OpenMP runtime in Further discussion on switching from GCC to Apple Clang should be done in a PR as this is a breaking feature change rather than a bug fix. It will negatively impact GCC users and resulting binaries may require users to use more hacks/workarounds to build Fortran code. So this may not be a viable option until Flang is stable enough to try using as a dependency. As side note, if you don't care about OpenMP and don't need static compilation, then you can try overriding the variable: ❯ PKG_CONFIG_PATH=$(brew --prefix openblas)/lib/pkgconfig pkg-config --define-variable=omp_opt= --cflags --libs openblas
-I/opt/homebrew/Cellar/openblas/0.3.29/include -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblasBeyond this, you may want to create a modified copy of OpenBLAS in your own tap either with your own patches or using pthreads. |
Certainly, but how about creating an alternative formula which uses This would allow the use of the clang+gfortran toolchain (not 100% sure whether it matters which clang it is, Apple or Homebrew/llvm, hopefully these two are interchangeable) without extra worries about |
|
That's something you should use a tap for - https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap |
|
Sure, but why would the more usual toolchain support be delegated to a tab, while an admittedly niche gcc-only toolchain be imposed by default ? And, in particular, without any documentation, any warnings in this regard ? Do you really expect that everyone knows not to mix two different OpenMP libraries? |
|
In the past, we supported 2 variants, a default "Apple clang + pthreads" and an optional "GCC + libgomp". When we removed support for options, we chose the most popular variant based on analytics data: So not a niche choice when majority of Homebrew users chose that and have been using it for at least 6 years now. Anyways, closing this issue as we don't use issues for new formula requests. And marking original headline topic as unsupported. If you want to discuss further about new formula, please open a pull request. I will note that "Apple clang + libomp" will probably require a minimum of upstream agreement for support at OpenMathLib/OpenBLAS#5169. Currently doesn't seem to be planned.
Also, I don't think *BSD would have issues as long as they do a complete LLVM build. As example, the brew ❯ $(brew --prefix llvm)/bin/clang -fopenmp test.c -o test
❯ otool -L test
test:
/opt/homebrew/opt/llvm/lib/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0) |
This is a very skewed way to measure popularity. And you haven't said anything about improving documentation. How would another user not run into the same trap as I did ? You cannot expect a user to know that once there were 2 versions of the formula, and the surviving formula is just one of them remaining, while the other one is gone, and to know which one of the 2 actually survived, as the important information: the platform, once encoded in the options, is gone. |
@dimpase Since gfortran -fopenmp -c test.f90 -o test.o
gfortran -L/opt/homebrew/opt/libomp/lib -lomp test.o -o test
PROGRAM Test
USE OMP_LIB
!$OMP PARALLEL
CALL SLEEP(10)
PRINT *, "Hello from process: ", OMP_GET_THREAD_NUM()
!$OMP END PARALLEL
END |
|
Conda people say that they simply make libgomp.dylib a symlink to libomp.dylib, and it all works. |
Then the "Apple clang + libomp" build of |
|
Please have a look at OpenMathLib/OpenBLAS#5180 where one can build openblas with the Brew apple-clang + gfortran + libomp toolchain, using cmake. |
brew gist-logs <formula>link ORbrew configANDbrew doctoroutput(I'm not root on the machine, so I can't meaningfully run
brew doctor)I asked a root for the output of
brew gist-logs openblas, still waiting.EDIT: the root replied with
Verification
brew doctoroutput saysYour system is ready to brew.and am still able to reproduce my issue.brew updateand am still able to reproduce my issue.brew doctorand that did not fix my problem.What were you trying to do (and why)?
I am trying to use Homebrew's openblas with XCode C compiler, Apple's clang:
Openblas is located in
/opt/homebrew/Cellar/openblas/0.3.29/and itsopenblas.pcproduces the following CFLAGS:Such flags are not accepted by Apple's clang.
Specifically, on gets:
The correct format for the OpenMP option is
-Xclang -fopenmp,as can be checked directly, or read on the R Project website: https://mac.r-project.org/openmp/
Thus,
openblas.pchas to be fixed, but it's probably only opening a can of worms, as I have no idea whetherlibgomp, against whichlibopenblasis linked, is compatible with Apple clang's support of OpenMP.What happened (include all command output)?
What did you expect to happen?
It should work.
Step-by-step reproduction instructions (by running
brewcommands)The text was updated successfully, but these errors were encountered: