Skip to content

Adopt meson-python install_rpath for runtime library paths - #274

Draft
antonwolfy wants to merge 2 commits into
mainfrom
chore/adopt-install-rpath-meson-python-0.22
Draft

antonwolfy wants to merge 2 commits into
mainfrom
chore/adopt-install-rpath-meson-python-0.22

Conversation

@antonwolfy

Copy link
Copy Markdown
Collaborator

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.

Consolidate the installed runtime library search paths into a single
install_rpath argument on the loops shared library and both extension
modules, replacing the previous -Wl,-rpath link_args workaround.

meson-python 0.22 honors install_rpath and no longer preserves the
RPATH entries meson auto-inserts for internal link_with dependencies,
so the extension modules could no longer locate the co-located
libmkl_umath_loops.so at import time on Linux/macOS. Requesting the
package directory ($ORIGIN / @loader_path) via install_rpath restores
that, and folds the MKL runtime search paths into the same mechanism.

Raise the minimum build-time meson-python requirement to 0.22.0 in
pyproject.toml and both conda recipes accordingly.
@antonwolfy

antonwolfy commented Sep 28, 2026 •

Copy link
Copy Markdown
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant