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] Target CPU autodetection makes binaries undeployable #12705

Open
nenomius opened this issue Aug 31, 2022 · 3 comments
Open

[OpenBLAS] Target CPU autodetection makes binaries undeployable #12705

nenomius opened this issue Aug 31, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@nenomius
Copy link

https://github.com/xianyi/OpenBLAS#normal-compile says this:

Simply invoking make (or gmake on BSD) will detect the CPU automatically. To set a specific target CPU, use make TARGET=xxx, e.g. make TARGET=NEHALEM.

Current recipe does not set that:

def _configure_cmake(self):

This results in OpenBLAS autodetecting CPU features to build for using build-server CPU info, which makes resulting binaries broken for any CPU that don't have some of instruction sets that happened to be available at build time (crashes on illegal instructions and similar fun things).

@uilianries uilianries added the bug Something isn't working label Aug 31, 2022
@uilianries
Copy link
Member

@nenomius Any specific target that you are using and failed?

@nenomius
Copy link
Author

@uilianries
Ubuntu 20.04 x86_64.
We have Intel CPU with AVX512 supported on build-server, and some production servers don't have AVX512 supported. Those servers got crashes with SIGILL on instructions from AVX512 set.
We got OpenBLAS as dependency of dependency and i don't (yet) have minimal repro.

@uilianries
Copy link
Member

@nenomius okay, it explains better. PLease, for future issues, when something is not working, you can open using the bug template, which contains a nice form which help us to reproduce your scenario.

Anyway, we will need to update that recipe. The thing is, we use cmake to build, so we will need to find some way to pass targets name to cmake and work just like for make command.

aborzunov added a commit to aborzunov/conan-center-index that referenced this issue Oct 14, 2022
aborzunov added a commit to aborzunov/conan-center-index that referenced this issue Oct 14, 2022
aborzunov added a commit to aborzunov/conan-center-index that referenced this issue Oct 14, 2022
aborzunov added a commit to aborzunov/conan-center-index that referenced this issue Oct 14, 2022
aborzunov added a commit to aborzunov/conan-center-index that referenced this issue Oct 14, 2022
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

Successfully merging a pull request may close this issue.

2 participants