Linking MKL fails at runtime phase

[cielavenir]

Environment: Debian 13 stable, libmkl-dev and mold packages are installed.

CMakeLists.txt

find_package(BLAS)

add_executable(test func.cpp main.c)
target_link_libraries(test ${BLAS_LIBRARIES} -fuse-ld=mold)

main.c

void func();
int main(){func();}

func.cpp

/// https://www.r-ccs.riken.jp/wp-content/uploads/2019/05/nakata190523.pdf ///

#include <stdio.h>
#include <cblas.h>
#include <dlfcn.h>

//Matlab/Octave format
void printmat(int N, int M, double *A, int LDA) {
double mtmp; printf("[ ");
for (int i = 0; i < N; i++) { printf("[ ");
for (int j = 0; j < M; j++) {       mtmp = A[i + j * LDA]; printf("%5.2e", mtmp);       if (j < M - 1) printf(", ");     }
if (i < N - 1) printf("]; ");     else printf("] ");
}
printf("]");
}
extern "C" void func() {
        Dl_info dlinfo;
        dladdr((const void*)cblas_dgemm, &dlinfo);
        printf("cblas_dgemm is from %s\n",dlinfo.dli_fname);

int n = 3;
double alpha, beta;
double *A = new double[n*n]; double *B = new double[n*n]; double *C = new double[n*n];
A[0+0*n]=1; A[0+1*n]= 8; A[0+2*n]= 3;   A[1+0*n]=2; A[1+1*n]=10; A[1+2*n]= 8;   A[2+0*n]=9; A[2+1*n]=-5; A[2+2*n]=-1;
B[0+0*n]=9; B[0+1*n]= 8; B[0+2*n]=3;   B[1+0*n]=3; B[1+1*n]=11; B[1+2*n]=2.3;   B[2+0*n]=-8; B[2+1*n]= 6; B[2+2*n]=1;
C[0+0*n]=3; C[0+1*n]=3; C[0+2*n]=1.2;   C[1+0*n]=8; C[1+1*n]=4; C[1+2*n]=8;   C[2+0*n]=6; C[2+1*n]=1; C[2+2*n]=-2;
printf("# dgemm demo...\n");
printf("A =");printmat(n,n,A,n);printf("\n");
printf("B =");printmat(n,n,B,n);printf("\n");
printf("C =");printmat(n,n,C,n);printf("\n");
alpha = 3.0; beta = -2.0;
cblas_dgemm(CblasColMajor,CblasNoTrans,CblasNoTrans, n, n, n, alpha, A, n, B, n, beta, C, n);
printf("alpha = %5.3e\n", alpha); printf("beta  = %5.3e\n", beta);
printf("ans=");printmat(n,n,C,n);printf("\n");
printf("#check by Matlab/Octave by:\n");
printf("alpha * A * B + beta * C =\n");
delete[]C; delete[]B; delete[]A;
}

With libmkl-dev is installed, the cmake picks up -- Found BLAS: /usr/lib/x86_64-linux-gnu/libmkl_intel_lp64.so;/usr/lib/x86_64-linux-gnu/libmkl_intel_thread.so;/usr/lib/x86_64-linux-gnu/libmkl_core.so;/usr/lib/x86_64-linux-gnu/libiomp5.so;-lm;-ldl.

Then, the "test" executable is created, but cannot run it

$ ./test 
./test: symbol lookup error: /lib/x86_64-linux-gnu/libmkl_intel_lp64.so: undefined symbol: mkl_lapack_zhesvxx

Expected behavior is:

$ ./test 
cblas_dgemm is from /lib/x86_64-linux-gnu/libmkl_intel_lp64.so
# dgemm demo...
A =[ [ 1.00e+00, 8.00e+00, 3.00e+00]; [ 2.00e+00, 1.00e+01, 8.00e+00]; [ 9.00e+00, -5.00e+00, -1.00e+00] ]
B =[ [ 9.00e+00, 8.00e+00, 3.00e+00]; [ 3.00e+00, 1.10e+01, 2.30e+00]; [ -8.00e+00, 6.00e+00, 1.00e+00] ]
C =[ [ 3.00e+00, 3.00e+00, 1.20e+00]; [ 8.00e+00, 4.00e+00, 8.00e+00]; [ 6.00e+00, 1.00e+00, -2.00e+00] ]
alpha = 3.000e+00
beta  = -2.000e+00
ans=[ [ 2.10e+01, 3.36e+02, 7.08e+01]; [ -6.40e+01, 5.14e+02, 9.50e+01]; [ 2.10e+02, 3.10e+01, 4.75e+01] ]
#check by Matlab/Octave by:
alpha * A * B + beta * C =

[cielavenir]

ldd test is like this

$ ldd test 
	linux-vdso.so.1 (0x00007f4d2aaa5000)
	libmkl_intel_lp64.so => /lib/x86_64-linux-gnu/libmkl_intel_lp64.so (0x00007f4d29c00000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4d29800000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d2960a000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d2aa52000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4d2a960000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4d2aaa7000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4d2a933000)

With -fuse-ld=bfd,

$ ldd test 
	linux-vdso.so.1 (0x00007f08f26d0000)
	libmkl_intel_lp64.so => /lib/x86_64-linux-gnu/libmkl_intel_lp64.so (0x00007f08f1800000)
	libmkl_intel_thread.so => /lib/x86_64-linux-gnu/libmkl_intel_thread.so (0x00007f08ede00000)
	libmkl_core.so => /lib/x86_64-linux-gnu/libmkl_core.so (0x00007f08e9600000)
	libomp.so.5 => /lib/x86_64-linux-gnu/libomp.so.5 (0x00007f08f254e000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f08e9200000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f08e900a000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f08f2547000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f08f2542000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f08f26d2000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f08f1710000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f08eddd3000)

You can see that libmkl_intel_thread.so and libmkl_core.so are omitted from NEEDED table even though they are present in link flag.

---

Actually the situation is similar with -fuse-ld=gold or -fuse-ld=lld, so I'm not sure what is the expected behavior,,,

[cielavenir]

By the way I say advance that using libmkl_rt is not a solution in this issue level; I once asked Intel10_64_dyn should be prioritized to Intel10_64lp, but it was rejected.

[bmilanich]

This is the issue with the libmkl_intel_lp64.so having undefined symbols and not referencing DSOs with those symbols. Both gold and mold won't try to resolve the undefined symbols in a DSO input so they won't pull in libmkl_core.so etc because they don't resolve any symbols in the .o inputs.

To get around this without rebuilding the libmkl_intel_lp64.so you need to specify--no-as-needed linker option (using -Wl,--no-as-needed in the compiler's command line) before the DSOs, which will force them to be referenced by the executable you are linking.