CI: Use VecLibFort as shim library for Apple Accelerate/VecLib on macOS. - #484
Conversation
|
Tick the box to add this pull request to the merge queue (same as
|
fghoussen
left a comment
fghoussen
left a comment
There was a problem hiding this comment.
Thanks! Can you update the CHANGELOG?
| export VECLIBFORT_PREFIX=$(brew --prefix veclibfort) | ||
| cmake \ | ||
| -DBLAS_LIBRARIES="${VECLIBFORT_PREFIX}/lib/libvecLibFort.dylib" \ | ||
| -DLAPACK_LIBRARIES="${VECLIBFORT_PREFIX}/lib/libvecLibFort.dylib" \ |
There was a problem hiding this comment.
Possible to drop BLAS_LIBRARIES / LAPACK_LIBRARIES using BLA_VENDOR: can cmake handle that?
There was a problem hiding this comment.
There is no value of BLA_VENDOR that would identify the vecLibFort shim library:
https://cmake.org/cmake/help/latest/module/FindBLAS.html#blas-lapack-vendors
Alternatively, it would be possible to use OpenBLAS instead of Apple Accelerate/VecLib in the CI. OpenBLAS is (mostly) written in C implementing an interface that is compatible to the GNU Fortran ABI. So for OpenBLAS, no shim library is necessary.
There was a problem hiding this comment.
In the CI, better to use vecLib (OpenBLAS is already tested on other jobs).
There is no value of BLA_VENDOR
For me Apple means "use vecLib"
There was a problem hiding this comment.
For me Apple means "use vecLib"
Correct. But that is linking to vecLib directly (without the shim library vecLibFort).
I.e., that would cause issues because vecLib uses the old f2c Fortran ABI that should be avoided nowadays.
There was a problem hiding this comment.
OK. But does this mean both vecLib (set by BLA_VENDOR?) and vecLibFort must be passed to cmake? Or one out of both?
There was a problem hiding this comment.
If BLAS_LIBRARIES and LAPACK_LIBRARIES are set, BLA_VENDOR doesn't have any effect.
You can set it to anything(?). But that might be confusing imho. It probably fits the situation best to not set it at all.
There was a problem hiding this comment.
fits the situation best to not set it at all.
101% agree. Can you try to get minimal cmake settings? Is ideally setting BLA_VENDOR and not setting any BLAS_LIBRARIES / LAPACK_LIBRARIES possible?
There was a problem hiding this comment.
Like I wrote before: There is no value for BLA_VENDOR that would correspond to the vecLibFort shim library.
So, this is the minimal set of variables that need to be set.
There was a problem hiding this comment.
The only other alternative is to not use Apple Accelerate/vecLib and use a different implementation of BLAS/LAPACK instead. That could be OpenBLAS (for which CMake implemented an identifier in its BLA_VENDOR selection).
But you already wrote that you didn't want that either.
Done. (Note that is likely introducing a merge conflict with #483.) |
Currently, the CI rules are building ARPACK using the old `f2c` Fortran ABI. However, all packages of applications written in Fortran that are distributed by Homebrew are using the default GNU Fortran ABI. Testing the package with the ABI expected by most macOS users would probably be better than what is currently done in the CI setup. Instead of building a version of ARPACK using that old, non-default `f2c` Fortran ABI, use a library that "translates" from the default GNU Fortran ABI to the old `f2c` ABI used by Apple Accelerate/VecLib.
|
@mmuetzel: thanks! |
2 participants
Pull request purpose
Currently, the CI rules are building ARPACK using the old
f2cFortran ABI on macOS. However, all packages of applications written in Fortran that are distributed by Homebrew are using the default GNU Fortran ABI. Testing the package with the ABI expected by most macOS users would probably be better than what is currently done in the CI setup.Detailed changes proposed in this pull request
Instead of building a version of ARPACK using that old, non-default
f2cFortran ABI, use a library that "translates" from the default GNU Fortran ABI to the oldf2cABI used by Apple Accelerate/VecLib.