I compiled OpenBLAS 0.3.30 on a VM with AlmaLinux 9, and I am experiencing a SIGILL while loading the numpy python module (which uses libopenblas-r0.3.30.so).
The cpu supports x86_64-v3:
$ /usr/lib64/ld-linux-x86-64.so.2 --help
. . .
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
. . .
I compiled with spack for x86_64-v3 with these specs:
^openblas@0.3.30~bignuma~consistent_fpcsr+dynamic_dispatch+fortran~ilp64+locking+pic+shared build_system=makefile symbol_suffix=none threads=none platform=linux os=almalinux9 target=x86_64_v3 %c,cxx,fortran=gcc@11.5.0
as a dependence for py-numpy, but now when I do import numpy I get a SIGILL:
$ dmesg -T | tail -n 1
[Sun Jun 7 22:24:24 2026] traps: python3[2714035] trap invalid opcode ip:7f361685ba20 sp:7ffe39e391e8 error:0 in libopenblas-r0.3.30.so[7f3615fa8000+1e5c000]
This happens also for a version compiled with x86_64 target. But if I specify a value for OPENBLAS_CORETYPE then it works (tried with Nehalem and Zen).
I suspect that the reason could be a fault in detecting the CPU architecture, which is circumvented by explicitly specifying it at runtime. Actually lscpu reports:
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 40 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: AuthenticAMD
Model name: QEMU Virtual CPU version 2.5+
CPU family: 15
. . .
so maybe the Model name: value is not correctly recognized?
I compiled OpenBLAS 0.3.30 on a VM with AlmaLinux 9, and I am experiencing a SIGILL while loading the
numpypython module (which uses libopenblas-r0.3.30.so).The cpu supports x86_64-v3:
I compiled with spack for x86_64-v3 with these specs:
as a dependence for py-numpy, but now when I do import numpy I get a SIGILL:
This happens also for a version compiled with
x86_64target. But if I specify a value forOPENBLAS_CORETYPEthen it works (tried with Nehalem and Zen).I suspect that the reason could be a fault in detecting the CPU architecture, which is circumvented by explicitly specifying it at runtime. Actually lscpu reports:
so maybe the
Model name:value is not correctly recognized?