-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[OpenBLAS] conanfile.py assumes gfortran compiler #1867
Comments
This is a hidden system requirement anyway which we should avoid in the mid-term I believe once we have LLVM packages we should package Flang and add it as a requirement |
@Croydon your suggestion is a good mid-term solution. Do you have any recommendation how to extend the existing approach until then? Would the following be appropriate:
|
I don't have a strong opinion either way, but I think such an option could be fine |
We now have a gfortan package which re-packages official binaries for Windows, Linux and macOS. Better than nothing |
- Allow disabling AVX512 via env variable, workaround for conan-io#12705 - Only make gfortran a dependency if actually used, related to conan-io#5910, conan-io#1867, conan-io#5338 - Add latest OpenBLAS release version 0.3.23 - Move replace_in_file to patches instead - Fix intel fortran compiler identification in OpenBLAS cmake - Allow build_lapack without fortran using C_LAPACK since 0.3.23
- Allow disabling AVX512 via env variable, workaround for conan-io#12705 - Only make gfortran a dependency if actually used, related to conan-io#5910, conan-io#1867, conan-io#5338 - Add latest OpenBLAS release version 0.3.23 - Move replace_in_file to patches instead - Fix intel fortran compiler identification in OpenBLAS cmake - Allow build_lapack without fortran using C_LAPACK since 0.3.23
- Allow disabling AVX512 via env variable, workaround for conan-io#12705 - Only make gfortran a dependency if actually used, related to conan-io#5910, conan-io#1867, conan-io#5338 - Add latest OpenBLAS release version 0.3.23 - Move replace_in_file to patches instead - Fix intel fortran compiler identification in OpenBLAS cmake - Allow build_lapack without fortran using C_LAPACK since 0.3.23
- Allow disabling AVX512 via env variable, workaround for conan-io#12705 - Only make gfortran a dependency if actually used, related to conan-io#5910, conan-io#1867, conan-io#5338 - Add latest OpenBLAS release version 0.3.23 - Move replace_in_file to patches instead - Fix intel fortran compiler identification in OpenBLAS cmake - Allow build_lapack without fortran using C_LAPACK since 0.3.23
- Allow disabling AVX512 via env variable, workaround for conan-io#12705 - Only make gfortran a dependency if actually used, related to conan-io#5910, conan-io#1867, conan-io#5338 - Add latest OpenBLAS release version 0.3.23 - Move replace_in_file to patches instead - Fix intel fortran compiler identification in OpenBLAS cmake - Allow build_lapack without fortran using C_LAPACK since 0.3.23
- Allow disabling AVX512 via env variable, workaround for conan-io#12705 - Only make gfortran a dependency if actually used, related to conan-io#5910, conan-io#1867, conan-io#5338 - Add latest OpenBLAS release version 0.3.23 - Move replace_in_file to patches instead - Fix intel fortran compiler identification in OpenBLAS cmake - Allow build_lapack without fortran using C_LAPACK since 0.3.23
conan-center-index/recipes/openblas/all/conanfile.py
Lines 87 to 88 in 5e30b91
gfortran is not the only Fortran compiler supported to compile OpenBLAS. Sometimes gfortran is a no-go as it introduces a runtime dependency on the GPL
libgfortran.so
. When redistributing artifacts with runtime dependency onlibgfortran.so
,libgfortran.so
would need to be redistributed as well. However, many organizations (eg. Apache Software Foundation) have policies against redistributing GPL artifacts.Relying on a system
libgfortran.so
is not an option either, as gfortran breaks ABI regularly:Flang Fortran compiler can be used instead of gfortran and does not introduce runtime dependencies on GPL libraries. Flang toolchain can be obtained via https://github.com/flang-compiler/flang/releases and for example OpenBLAS compiled via
CC=gcc make DYNAMIC_ARCH=1 USE_OPENMP=1 FC=flang
What's the best way to structure a conanfile.py to support different fortran toolchains? Should I open an issue about fortran compile support at https://github.com/conan-io/conan/ as well?
The text was updated successfully, but these errors were encountered: