Adopt meson-python install_rpath for runtime library paths

[antonwolfy]

This PR migrates the installed RPATH handling to meson-python's install_rpath argument and raises the minimum build-time meson-python requirement to 0.22.0.

Previously the runtime library search paths were injected as raw -Wl,-rpath,... link_args, which existed only because meson-python < 0.22 ignored the install_rpath argument. meson-python 0.22 (released 2026-09-25) adds first-class install_rpath support and, in the same release, stops preserving the $ORIGIN RPATH that Meson auto-inserts for internal link_with dependencies. The extension modules relied on that auto-inserted entry to locate the co-located libmkl_umath_loops.so, so builds against meson-python 0.22 fail at import time on Linux:

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

This surfaced as red test_linux jobs on unrelated PRs (e.g. #273) with no code change, once conda-forge shipped meson-python 0.22.

[antonwolfy]

Blocked on Python 3.10 support — revisit once 3.10 is dropped

The build_linux (3.10, ...) and build_windows (3.10, ...) jobs fail here (all other Python versions pass). Root cause is the meson-python>=0.22.0 floor this PR introduces, not the RPATH change itself:

• install_rpath support (what this PR migrates to) was added in meson-python 0.22.0.
• On conda-forge, meson-python dropped Python 3.10 at 0.21.0 (its depends became python >=3.11); 0.20.0 is the last conda-forge build that supports 3.10. This is a conda-forge packaging decision via the global python_min bump — upstream PyPI 0.22.0 still declares requires-python >=3.10.
• Net: there is no conda-forge meson-python that both builds for Python 3.10 and honors install_rpath, so meson-python>=0.22 cannot be satisfied in the 3.10 build environment. The solver reports the conflict as meson-python >=0.22.0 vs python =3.10 (the _python_rc / 3.14.0rc1 lines in the log are just the solver's noisy hint).

conda-forge dependency floor by version, for reference:

meson-python (conda-forge)	python requirement	install_rpath
0.20.0	>=3.10	no
0.21.0	>=3.11	no
0.22.0	>=3.11	yes

The RPATH change itself is validated: the Linux 3.11+ conda builds produce extension modules with the intended RPATH ($ORIGIN:$ORIGIN/../..:$ORIGIN/../../.. plus the env lib), and both clang build jobs are green.

Plan

Keep this PR open. Revise/merge it once the project drops Python 3.10 (requires-python = ">=3.11" and 3.10 removed from the CI matrices and classifiers) — at that point this clean install_rpath migration with the meson-python>=0.22 floor applies without conflict.

[jharlow-intel]

Thanks for exploring this! Using install_rpath is the cleaner long-term setup, and the comment explaining each path is really helpful. Since #275 already fixed the ImportError and shipped in 0.6.0, I think the main question is timing; a couple of thoughts below.

• Now that #275 covers the meson-python 0.22 case on every version, do we still want this, or should we park it until the floor can move? It also conflicts with main on the same meson.build lines, and when rebasing, the changelog entry would need to move out of the released 0.6.0 section.

[jharlow-intel]

I think this one needs sorting out before merge: the 0.22 floor would drop Python 3.10 from the conda builds. conda-forge's meson-python 0.22 packages are noarch with python >=3.11, so a 3.10 env can't solve, which matches the CI here (only the 3.10 builds fail, and the rest were cancelled). PyPI's 0.22 still supports 3.10, so it's just the conda side. Worth keeping the raw link_args from #275 until 3.10 is dropped?

[antonwolfy]

Yes, the idea is to keep the PR as draft until support of python 3.10 is dropped