Source: intel-mkl Version: 2020.4.304-4 Severity: normal X-Debbugs-Cc: poulios.konstanti...@gmail.com
Dear Maintainer, This package is listed in update-alternatives for providing blas and lapack implementations, however it is known that Intel and GNU blas implementations are not ABI compatible. The difference comes from how complex functions in Fortran return their value (by value or as a first argument). See section about Fortran bindings in https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p1674r2.html Test demonstrating the incompatibility: echo " #include <iostream> #include <complex> extern \"C\" { void cdotu_(std::complex<float> *, const int *, const std::complex<float> *, const int *, const std::complex<float> *, const int *); } int main() { const int one=1; std::complex<float> x(1.,2.), y(1.,-2.), result; cdotu_(&result, &one, &x, &one, &y, &one); std::cout<<result<<std::endl; return (fabs(result.real() - 5.) < 1e-8); } " > test_blas_cplx_abi.cc g++ test_blas_cplx_abi.cc -lopenblas -o test_blas_cplx_abi_openblas g++ test_blas_cplx_abi.cc -lmkl_rt -o test_blas_cplx_abi_mkl_rt Results: $ ./test_blas_cplx_abi_openblas (0,0) $ ./test_blas_cplx_abi_mkl_rt (5,0) The same issue affects both libblas and liblapack alternatives. Best regards Kostas -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled