Skip to content
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

Open
leezu opened this issue Jun 8, 2020 · 4 comments
Open

[OpenBLAS] conanfile.py assumes gfortran compiler #1867

leezu opened this issue Jun 8, 2020 · 4 comments
Labels
bug Something isn't working

Comments

@leezu
Copy link

leezu commented Jun 8, 2020

if self.options.build_lapack:
self.cpp_info.system_libs.append("gfortran")

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 on libgfortran.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?

@leezu leezu added the bug Something isn't working label Jun 8, 2020
@Croydon
Copy link
Contributor

Croydon commented Jun 9, 2020

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

@leezu
Copy link
Author

leezu commented Jun 11, 2020

@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:

@Croydon
Copy link
Contributor

Croydon commented Jun 11, 2020

I don't have a strong opinion either way, but I think such an option could be fine

@Croydon
Copy link
Contributor

Croydon commented Jan 26, 2021

We now have a gfortan package which re-packages official binaries for Windows, Linux and macOS. Better than nothing

#4249

joakimono added a commit to joakimono/conan-center-index that referenced this issue Apr 23, 2023
    - 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
joakimono added a commit to joakimono/conan-center-index that referenced this issue Apr 23, 2023
    - 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
joakimono added a commit to joakimono/conan-center-index that referenced this issue Apr 23, 2023
    - 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
joakimono added a commit to joakimono/conan-center-index that referenced this issue May 3, 2023
    - 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
joakimono added a commit to joakimono/conan-center-index that referenced this issue May 8, 2023
    - 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
joakimono added a commit to joakimono/conan-center-index that referenced this issue May 10, 2023
    - 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants