meson-python duplicate lc_rpath

[tboudreaux]

Putting this here as I suspect the issue is related to a misconfiguration on my machine rather than a bug in meson-python.

When building with meson python on a recent version of macOS I can no longer import my module.

import gridfire

ImportError: dlopen(/opt/homebrew/anaconda3/envs/fourdstar/lib/python3.13/site-packages/gridfire.cpython-313-darwin.so, 0x0002): tried: '/opt/homebrew/anaconda3/envs/fourdstar/lib/python3.13/site-packages/gridfire.cpython-313-darwin.so' (duplicate LC_RPATH '@loader_path/.gridfire.mesonpy.libs'), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/anaconda3/envs/fourdstar/lib/python3.13/site-packages/gridfire.cpython-313-darwin.so' (no such file), '/opt/homebrew/anaconda3/envs/fourdstar/lib/python3.13/site-packages/gridfire.cpython-313-darwin.so' (duplicate LC_RPATH '@loader_path/.gridfire.mesonpy.libs')

When I inspect the shared object file with otool I see that it contains many duplicate LC_RPATH entries

otool -l gridfire.cpython-313-darwin.so | grep RPATH -A2

          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path @loader_path/.gridfire.mesonpy.libs (offset 12)
--
          cmd LC_RPATH
      cmdsize 56
         path /opt/homebrew/Cellar/openssl@3/3.5.2/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path /opt/homebrew/Cellar/xz/5.8.1/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path /opt/homebrew/opt/zstd/lib (offset 12)

If I manually remove all but one of the rpath instances using install_name_tool

install_name_tool -delete_rpath @loader_path/.gridfire.mesonpy.libs

Then I can import and use my module just fine. Presumably then I could write some somewhat convoluted but not too complex tool to use otool to count the number of duplicate paths and remove them; however, I'm sure this strikes me as a one-way street to a bad time (lack of portability, and just a generally convoluted build step).

Other discussions (facebook/zstd#4369, https://fenicsproject.discourse.group/t/duplicate-lc-rpath-errors-on-macos-15-4-sequoia/17364) have pinpointed this change in behavior with recent versions of apple's XCode command line tools. Specifically that duplicate lc_rpaths are now treated as an error when loading shared libraries.

My question then is how do I prevent meson-python from adding all these duplicate paths to the shared object file?

Details

• macOS Version 26.0.1
• CLITools version : 26.0.0.0.1.1757719676
• meson-python version: 0.18.0
• meson version: 1.9.1
• clang version: Apple clang 17.0.0 (clang-1700.3.19.1)

Other details

• I have tried building with pip install . --no-cache-dir and pip install . --no-cache-dir --isolated and neither of these make a difference.
• I have confirmed the same behavior in my other mesonpy library, fourdst. I see the same behavior there where if I remove all but one of the rpath's using install_name_tool then I can import and use the module just fine
• When I inspect the shared library created by meson (which I belive is generated before meson-python steps in, though I may be mistaken, there are no duplicate lc_rpaths).

otool -l libgridfire.dylib | grep RPATH -A2

          cmd LC_RPATH
      cmdsize 72
         path @loader_path/../subprojects/libconstants/src/constants (offset 12)
--
          cmd LC_RPATH
      cmdsize 64
         path @loader_path/../subprojects/libconfig/src/config (offset 12)
--
          cmd LC_RPATH
      cmdsize 56
         path @loader_path/../subprojects/yaml-cpp (offset 12)
--
          cmd LC_RPATH
      cmdsize 72
         path @loader_path/../subprojects/libcomposition/src/composition (offset 12)
--
          cmd LC_RPATH
      cmdsize 64
         path @loader_path/../subprojects/liblogging/src/logging (offset 12)
--
          cmd LC_RPATH
      cmdsize 56
         path @loader_path/../subprojects/libplugin/src (offset 12)
--
          cmd LC_RPATH
      cmdsize 64
         path @loader_path/../subprojects/minizip-ng-4.0.10 (offset 12)
--
          cmd LC_RPATH
      cmdsize 56
         path @loader_path/../subprojects/cvode-7.3.0 (offset 12)
--
          cmd LC_RPATH
      cmdsize 56
         path /opt/homebrew/Cellar/openssl@3/3.5.2/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path /opt/homebrew/Cellar/xz/5.8.1/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path /opt/homebrew/opt/zstd/lib (offset 12)

[eli-schwartz]

meson-python/mesonpy/_rpath.py

Lines 41 to 44 in 3c6b89d

	def fix_rpath(filepath: Path, libs_relative_path: str) -> None:
	for path in _get_rpath(filepath):
	if path.startswith('@loader_path/'):
	_replace_rpath(filepath, path, '@loader_path/' + libs_relative_path)

It looks like mesonpy replaces each rpath with its own internal rpath, rather than removing the ones it doesn't want and adding a single instance of the internal rpath.

(mesonpy.libs indeed doesn't come from Meson itself -- it's added during wheel generation postprocessing.)

[dnicolodi]

Yup, this is a bug, filed as #813. I think the bug is exposed by changes in macOS 26.1. Either otool in older macOS deduplicates the RPATH entries, or the dynamic loader in older macOS does not mind the duplicate entries.

@eli-schwartz is correct in the analysis. The RPATH handling in meson-python has known shortcomings. There have been a couple of attempts at fixing it, see the open PRs. Unfortunately, some projects coming to depend on the buggy behavior. Fixing meson-python without breaking these projects requires some attention. I think I identified a way to do it, but I haven't been able to find time to push the required changes. The thing has been given low priority because nothing broke badly, so far. With this new problem exposed, I'll go back to working on it ASAP.