Need to set LD_LIBRARY_PATH for 1.3.13

[jankrecke]

Hello,

Until recently I have been using mkl_fft 1.3.11 on Ubuntu 24.04 and I could install it without issues with uv from the Intel index.

Relevant section from the pyproject.toml:

[[tool.uv.index]]
name = "intel"
url = "https://software.repos.intel.com/python/pypi"

[tool.uv.sources]
mkl_fft = { index = "intel" }
numpy = { index = "intel" }

dependencies = [
"mkl-fft>=1.3.0",
"numpy>=1.21.6",
]

and uv.lock:

$ grep mkl_fft uv.lock
    { url = "https://software.repos.intel.com/python/pypi/mkl-fft/mkl_fft-1.3.11-81-cp312-cp312-manylinux_2_28_x86_64.whl", hash = "sha256:5561565f832a921eb08ce6adca04a9b03d03046ab60dfa4080d1342b803fd165" },
    { url = "https://software.repos.intel.com/python/pypi/mkl-fft/mkl_fft-1.3.11-81-cp312-cp312-win_amd64.whl", hash = "sha256:aad6ee1f290a0163246a0ccb8d761236e90a1fe5acc42b402ef71c6ca3ca6c4a" },

I accidentally updated to 1.3.13 after deleting my uv.lock file,

$ grep mkl_fft uv.lock
    { url = "https://software.repos.intel.com/python/pypi/mkl-fft/mkl_fft-1.3.13-0-cp312-cp312-manylinux_2_28_x86_64.whl", hash = "sha256:62d03c16defb78f73269087857f6a860345408e93c2717e8f0d4d5bfbaad3829" },
    { url = "https://software.repos.intel.com/python/pypi/mkl-fft/mkl_fft-1.3.13-0-cp312-cp312-win_amd64.whl", hash = "sha256:0d0a531ab5d443c5928d7f6cbfdce5d4f73811f7bab2cf72c9fb2305fe037ca3" },

and now I get an error that culminates in

ImportError: libintlc.so.5: cannot open shared object file: No such file or directory

which can be fixed by

export LD_LIBRARY_PATH=/path/to/my/.venv/lib/

In general that's not a problem and can be handled in my Dockerfile.

But I'm surprised that there would be this change of behaviour from 1.3.11 to 1.3.13. Is that by design? Or am I missing something?

I thank you very much in advance and look forward to hearing from you! Please let me know if you need any more information.

[vtavana]

Hello,

Thank you for reporting it.

When you install mkl_fft, mkl_random and mkl_umath are also installed with it and it seems the issue you are pointing out is related to mkl_umath=0.1.4.

I am able to replicate the issue in a venv where mkl_fft=1.3.13 and mkl_umath=0.1.4 are installed.

$ python3 -m venv umath_014_env
$ source umath_014_env/bin/activate
$ python -m pip install --index-url https://software.repos.intel.com/python/pypi mkl_fft 
# Successfully installed intel-cmplr-lib-rt-2025.1.0 intel-cmplr-lib-ur-2025.1.0 intel-openmp-2025.1.0 mkl-2025.1.0 
# mkl-service-2.4.2 mkl_fft-1.3.13 mkl_random-1.2.10 mkl_umath-0.1.4 numpy-1.26.4 tbb-2022.1.0 tbb4py-2022.1.0 
# tcmlib-1.3.0 umf-0.10.0

>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~/umath_014_env/lib/python3.10/site-packages/numpy/__init__.py", line 446, in <module>
    import mkl_umath
  File "~/umath_014_env/lib/python3.10/site-packages/mkl_umath/__init__.py", line 34, in <module>
    from ._ufuncs import *
ImportError: libintlc.so.5: cannot open shared object file: No such file or directory

However, there is no issue in a venv where mkl_fft=1.3.13 and mkl_umath=0.1.2 are installed.

$ python3 -m venv umath_012_env
$ source umath_012_env/bin/activate
$ python -m pip install --index-url https://software.repos.intel.com/python/pypi mkl_fft mkl_umath==0.1.2
# Successfully installed intel-cmplr-lib-rt-2025.1.0 intel-cmplr-lib-ur-2025.1.0 intel-openmp-2025.1.0 mkl-2025.1.0 
# mkl-service-2.4.2 mkl_fft-1.3.13 mkl_random-1.2.10 mkl_umath-0.1.2 numpy-1.26.4 tbb-2022.1.0 tbb4py-2022.1.0 
# tcmlib-1.3.0 umf-0.10.0

>>> import mkl_umath, mkl_fft, mkl_random
>>> mkl_umath.__version__
'0.1.2'
>>> mkl_random.__version__
'1.2.10'
>>> mkl_fft.__version__
'1.3.13'
>>> import numpy
>>> numpy.ones(5)
array([1., 1., 1., 1., 1.])

We will look at it in more detail in mkl_umath package and hopefully fix the issue. Thank you again for reporting it.

[jankrecke]

I can confirm that with mkl_umath == 0.1.2 I don't see the issue

[ekomarova]

Hi!
The regression between mkl_umath versions 0.1.2 and 0.1.4 is caused by a change in the RPATH configuration of the compiled extension module (_ufuncs.so).
0.1.2:

readelf -d umath_012/lib/python3.12/site-packages/mkl_umath/_ufuncs.cpython-312-x86_64-linux-gnu.so | grep PATH
 0x000000000000000f (RPATH)           Library rpath: [/../..:/../../..:/home/sat_bot/base/conda-bld/numpy_and_dev_1729729056337/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib:$ORIGIN/../..:$ORIGIN/../../..:$ORIGIN]

0.1.4:

readelf -d umath_014/lib/python3.12/site-packages/mkl_umath/_ufuncs.cpython-312-x86_64-linux-gnu.so | grep PATH
 0x000000000000000f (RPATH)            Library rpath: [/home/sat_bot/base/conda-bld/numpy_and_dev_1742924039955/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib:$ORIGIN]

Although the code did not change between the versions, the newer build no longer includes relative RPATH entries like $ORIGIN/../.., which previously allowed the runtime linker to locate required shared libraries such as libintlc.so.5 bundled within the wheel. As a result, when using version 0.1.4, the interpreter fails to locate the library at runtime, leading to an ImportError.

But it's a bit difficult to say what exactly the reason is. Something could have changed in the build environment or toolchain (e.g., conda-build, setuptools, patchelf, or auditwheel) rather than changes in the source code itself.

There is an idea to update Cmake by adding INSTALL_RPATH "$ORIGIN;$ORIGIN/..;$ORIGIN/../.." there, but we need to test this solution. In any case, as @vtavana mentioned, it looks like a fix is required on mkl_umath side only.

[jankrecke]

Thanks @vtavana and @ekomarova!

I don't think there's an issue using mkl_umath 0.1.2 for now. But I'm glad that you guys are working on a solution, thanks! 😊 I think it would be kind of annoying having to manage the library path manually in future releases 🙇

[ekomarova]

Hi, @jankrecke! We have released the fixed mkl_umath version 0.1.5. Now it works:

>> python -m venv umath_015
>> source umath_015/bin/activate
>> python -m pip install --index-url https://software.repos.intel.com/python/pypi mkl_fft mkl_umath==0.1.5
>> pip list
Package            Version
------------------ --------
intel-cmplr-lib-rt 2025.1.0
intel-cmplr-lib-ur 2025.1.0
intel-openmp       2025.1.0
mkl                2025.1.0
mkl_fft            1.3.13
mkl_random         1.2.10
mkl-service        2.4.2
mkl_umath          0.1.5
numpy              1.26.4
pip                24.3.1
tbb                2022.1.0
tbb4py             2022.1.0
tcmlib             1.3.0
umf                0.10.0
>> python
Python 3.12.9 | packaged by conda-forge | (main, Mar  4 2025, 22:48:41) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import mkl_fft
>>> import mkl_umath
>>>

Please retest it again and we will close the issue 😊

[jankrecke]

It works! The problem is gone with mkl_umath==0.1.5 👍.

I will close this issue, thanks again for your quick support 😊