mamba-org
py-rattler `install` with a relative prefix path results in invalid dynamic library dependency paths
Checklist
- [x] I added a descriptive title
- [x] I searched open reports and couldn't find a duplicate
What happened?
After switching from mamba to py-rattler in my project, I started getting occasional strange behavior where files couldn't be found. Consider an environment conda with ncurses installed:
$ otool -L conda/lib/libncurses.6.dylib
conda/lib/libncurses.6.dylib:
@rpath/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
conda/lib/libtinfo.6.dylib (compatibility version 6.0.0, current version 6.0.0, reexport)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
Shouldn't libtinfo.6.dylib be one of @loader_path/libtinfo.6.dylib or perhaps @loader_path/../lib/libtinfo.6.dylib?
Edit:
I see that LC_RPATH is set to @loader_path/, so I believe it should be @rpath/libtinfo.6.dylib or @rpath/../lib/libtinfo.6.dylib
Additional Context
No response
Is this only with the most recent py-rattler releases? We changed to use "abi3" format and that might have triggered this.
I was able to test as far back as 0.6.0 and it had the same behavior.
Upon further inspection, it looks like ncurses is the only package in my entire package cache that has a placeholder dynamic dependency:
/Users/runner/miniforge3/conda-bld/ncurses_1738195744584/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib/libtinfo.6.dylib (compatibility version 6.0.0, current version 6.0.0, reexport)
Every other dylib already has @rpath
Looks like I was a little wrong, the placeholder is supposed to be replaced with the full path. I was able to fix my build by calling pathlib.Path.absolute on the prefix! It seems like maybe that should be done by rattler to avoid this bug?
