auditwheel icon indicating copy to clipboard operation
auditwheel copied to clipboard

Failure to package MKL dependency due to libmkl_core.so.2 not found

Open jdumas opened this issue 8 months ago • 2 comments

Hi,

I am trying to build a wheel for a Python package that depends on MKL. I am aware of #404 and #250, but I think my issue is a bit different. I'll eventually move towards depending explicitly on the PyPI MKL package, but for now I just want to graft the MKL dependency into my wheel.

The issue I am facing is that the auditwheel repair step fails because libmkl_core.so.2 cannot be found:

ValueError: Cannot repair wheel, because required library "libmkl_core.so.2" could not be located

Note: I am not trying to use the MKL SDL here (so no dlopen()). I am trying to link directly against the .so that I want.

If I run ldd I can see that my library correctly finds the libmkl_core.so.2 dependency:

jedumas@hostname ~/w/g/l/d/lagrange (jedumas/wheels)> ldd lagrange.cpython-311-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffcd07d7000)
        libmkl_intel_lp64.so.2 => /home/jedumas/workspace/github/lagrange/dist/lagrange/./libmkl_intel_lp64.so.2 (0x000078aa18a00000)
        libmkl_tbb_thread.so.2 => /home/jedumas/workspace/github/lagrange/dist/lagrange/./libmkl_tbb_thread.so.2 (0x000078aa16c00000)
        libmkl_core.so.2 => /home/jedumas/workspace/github/lagrange/dist/lagrange/./libmkl_core.so.2 (0x000078aa12c00000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000078aa1ba31000)
        libtbb.so.12 => /home/jedumas/workspace/github/lagrange/dist/lagrange/./libtbb.so.12 (0x000078aa19982000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000078aa12800000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000078aa19952000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000078aa12400000)
        /lib64/ld-linux-x86-64.so.2 (0x000078aa1bb2a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000078aa1994d000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000078aa19948000)

However, the MKL libraries that ship with the PyPI package itself cannot find libmkl_core.so.2 correctly:

jedumas@hostname ~/.c/C/m/c/m/d/lib> ldd libmkl_avx2.so.2
        linux-vdso.so.1 (0x00007ffd32083000)
        libmkl_core.so.2 => not found
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000072706ac60000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000727067e00000)
        /lib64/ld-linux-x86-64.so.2 (0x000072706ac75000)

My impression is that the lddtree function in auditwheel finds the first occurrence of libmkl_core.so.2 pointing to null (not found), and then just runs with that instead of using the libmkl_core.so.2 =>... reference found in lagrange.cpython-311-x86_64-linux-gnu.so. See the attached build log for the full debug output.

References

jdumas avatar Apr 14 '25 22:04 jdumas

This wouldn't be solved by #582 in its current state I think. It would likely require to implement a second pass once we have the results from all ldd calls in order to update the realpath of some objects. We'd likely need a minimal reproducer for this.

mayeut avatar May 25 '25 15:05 mayeut

I have some experience with this specific issue, the pypi mkl package would be installed to ../../libmkl*.so, i.e. venv/lib/libmkl*.so. This path is usually not recognized by auditwheel, you can add it to LD_LIBRARY_PATH manually.

Or you can use mkl-static, which is also on pypi and embed it into your library.

oraluben avatar May 26 '25 22:05 oraluben