How to install relocable shared lib on macOS (install_name set to @rpath)?

[SpaceIm]

I'm trying to fix meson based recipes in conan-center (https://github.com/conan-io/conan-center-index) regarding install_name in shared libs on macOS.

conan-center is supposed to provide fully relocatable packages, therefore absolute path in install_name is not an option. install_name must be @rpath. How to you achieve this behavior with Meson (except running otool manually which is something I want to avoid because it's tedious to automate)?

I'm also wondering why it's the default behavior in Meson? CMake default behavior is to set install_name to @rpath and cleanup RPATH in installed binaries, and I think it's a good default.

[eli-schwartz]

The use of @rpath is detected and forced into absolute paths in mesonbuild/scripts/depfixer.py`, and git blame points back to #3691

So the problem it is trying to fix is basically "everything is broken and horrible by default, except when you build a relocatable package which is not the default and requires more work than just using @rpath".

It was mentioned in the PR that it would be good to have a configure time option to choose which one you want, but that such an option wasn't a blocker for the PR because "it's already broken but this makes it work for at least some cases". A pretty strong stance, hmm. :)

And here we are 3.5 years later and no one has added (or even requested?) that option.

[SpaceIm]

Ok, I'm not asking to change default behavior, just to provide some option to set install_name to @rpath.

I've looked a little bit to this PR, and several comments in commits are quite surprising:

The install name is used by consumers of the library to find the
library at runtime. If it's @rpath/libfoo.dylib, all consumers must
manually add the library path to RPATH, which is not what people
expect.

CMake handles external lib path injection into RPATH of executables of the build tree out of the box.

Almost everyone sets the library install name as the full path to the
library, and this is done at install time with install_name_tool.

It's not the most flexible approach nowadays.

@nirbheek
[macos: Rewrite install_name for dependent built libraries on install](https://github.com/mesonbuild/meson/pull/3691/commits/105b966fa4343ff6fe49927eef5b84981237be5d)
[105b966](https://github.com/mesonbuild/meson/pull/3691/commits/105b966fa4343ff6fe49927eef5b84981237be5d)

On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).

However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.

We now change that install name to point to the absolute path to each
built library after installation.

Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077

With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.

Default behavior of CMake >= 3.0 is not the same than Autotools nor Meson (https://cmake.org/cmake/help/v3.0/policy/CMP0042.html and rational behind CMake logic: https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling#default-rpath-settings).
In CMake, running executables in the build tree linked to external shared libs having @rpath token works out of the box because CMake automatically add paths of these shared libs to LC_RPATH of executables in the build tree.
So basically people using CMake don't specially expect install_name to be absolute path. It's fine if they have built these external libs on their machine, that's all, but it breaks if they were built on another machine with different paths.