[LINUX] MKL taints symbol table (PLT / procedure linkage table)


Related to https://qiita.com/cielavenir/items/93d2b5b057bfe1383670.

Suppose you have A.so and B.so, A is statically linked to libmkl_rt and B is statically linked to libblas. At this time, if A.so and B.so are dynamically linked [^ 1], A should use libmkl_rt and B should use libblas for BLAS implementation. However, in reality, if A calls the BLAS function of MKL and then loads B, B will also use MKL for the BLAS implementation. This can be a problem if (unlikely) B depends on the behavior of BLAS implementations other than MKL [^ 2]. However, there seems to be no workaround this time ...


The binary package for scipy / spatial / qhull.so links to libopenblas, but running the following in the LD_DEBUG = "libs symbols" environment can load the MKL dgetrf / dgetrs / dgecon (instead of libopenblas) Be observed. Note that ╩╗import scipy` does not load scipy / spatial / qhull.so.

import numpy
import scipy  # this does not guarantee scipy.spatial safety.
points = numpy.random.rand(30, 2)  # 30 random points in 2-D

import ctypes
# this CDLL loads so using RTLD_LOCAL

print '=== check dgetrf/dgetrs/dgecon below ==='
from scipy.spatial import ConvexHull
hull = ConvexHull(points)

in conclusion

There was something I thought about, and when I added a pattern that uses multiple modules in the previous demo, I was able to reproduce it (because it uses the constructor attribute), it can be reproduced just by loading it without calling a function). Isn't libmkl_rt just doing that dlopen reopen to observe the behavior ...?

Recommended Posts

MKL taints symbol table (PLT / procedure linkage table)