Add an option to have @rpath install_name instead of an absolute path

[SoapGentoo]

Description

Meson's RPATH and install_name handling are currently broken on macOS. Here's a toy example. Let foo be the library (aka the provider) and let bar be the executable (aka the consumer). For foo we have: foo.cpp:

#include <iostream>

void foo_func()
{
    std::cout << "Hello World!\n";
}

foo.hpp:

void foo_func();

meson.build:

project('libfoo', 'cpp')

foo_lib = library('foo', 'foo.cpp', install : true)
install_headers('foo.hpp', subdir : 'foo')

import('pkgconfig').generate(
  libraries : foo_lib,
  version : '1.0',
  name : 'foo',
  filebase : 'foo',
  subdirs : 'foo',
  description : 'A foo library')

For bar we have: bar.cpp:

#include <foo.hpp>

int main()
{
    foo_func();
    return 0;
}

meson.build:

project('barapp', 'cpp')

foo_dep = dependency('foo')

# build_rpath is used here for test dependencies
executable('bar', 'bar.cpp', dependencies : foo_dep, build_rpath : foo_dep.get_pkgconfig_variable('libdir'))

How to reproduce

in foo (the rm -r build at the end is crucial to reproduce the issue):

meson.py --prefix /Users/Soap/Desktop/PREFIX/ build . && ninja -C build -v install && rm -r build

in bar:

export PKG_CONFIG_PATH=/Users/Soap/Desktop/PREFIX/lib/pkgconfig
meson.py --prefix /Users/Soap/Desktop/PREFIX/ build . && ninja -C build -v
./build/bar

which then greets you with a message:

dyld: Library not loaded: /Users/Soap/Desktop/foo/build/libfoo.dylib
  Referenced from: /Users/Soap/Desktop/bar/./build/bar
  Reason: image not found

The actual problem

The culprit is how meson builds libraries on macOS. The linking line is currently:

c++  -o libfoo.dylib 'foo@sha/foo.cpp.o' -shared -install_name /Users/Soap/Desktop/foo/build/libfoo.dylib '-Wl,-rpath,$ORIGIN/'

which is incorrect. MacOS has a peculiar and very unusual way of linking, namely that consumers of a library inherit a provider's install_name. If you run otool -l on the library you get

          cmd LC_ID_DYLIB
      cmdsize 72
         name /Users/Soap/Desktop/foo/build/libfoo.dylib (offset 24)

where the name is clearly wrong, as it uses the builddir name. As an absolute minimum this should have been /Users/Soap/Desktop/PREFIX/lib/libfoo.dylib (but hold on, you still don't want this). This is why, when not running rm -r build in foo, the linking seems to work, because bar is still using the build dir lib, not the installed one.

Furthermore, another peculiarity of macOS is the fact that for RPATH of consumers to work, the provider has to play along. This is different from Linux, where RPATH/RUNPATH are purely a consumer problem, the provider does not have to know about consumers' RPATH behaviour. Thus, in order for RPATH to work for consumers, the install_name has to be @rpath/<libname>.dylib. In a quick and hacky way, doing this in foo:

c++  -o libfoo.dylib 'foo@sha/foo.cpp.o' -shared -install_name @rpath/libfoo.dylib '-Wl,-rpath,$ORIGIN/'

And then in bar (notice the missing colon : after -Wl,-rpath,):

c++  -o bar 'bar@exe/bar.cpp.o' -L/Users/Soap/Desktop/PREFIX/lib -lfoo -Wl,-rpath,/Users/Soap/Desktop/PREFIX/lib

and then ./bar gives me

Hello World!

Conclusion

This issue is caused by macOS' unconventional linking behaviour, and the fact that library providers have to be RPATH aware, which is unduly burdensome and complicates things. I believe the following to be the best line of operation:

1. all (shared) libraries would use -install_name @rpath/<libname>.dylib unconditionally, purely to be consumed in an RPATH-capable way. While using an absolute install_name would make things a bit easier in the short run, this is short-sighted and a path full of pain. There are two reasons to avoid absolute install_names:
   1. reproducible builds, as this would code path/layout-dependent information into libraries
   2. it makes libraries non-relocatable, whereas relative RPATH-based builds are relocatable.
2. all consumers (that is, other libraries and executables) should specify RPATHs in a relative way, where @loader_path is the proper analogue to $ORIGIN on Linux.

References

https://github.com/conda/conda-build/issues/279 https://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpath http://jorgen.tjer.no/post/2014/05/20/dt-rpath-ld-and-at-rpath-dyld/

[mojca]

Getting this fixed is of critical importance for the ability to even consider using meson in our package manager on Mac. I would argue that meson should provide a configuration option to tell whether the final build should use relative or absolute paths. Not something that software developer themselves should worry about, but something that the people building software could specify (depending on whether they are building a bundled app or perhaps a package manager where location of files is fixed).

[ilovezfs]

This also impacts gobject-introspection files, which end up with the build path hard coded since they're taking their cues from the LC_ID_DYLIB. So even if you fix up the dylibs manually after installation, you still have broken gobject-introspection files.

[mojca]

See https://github.com/mesonbuild/meson/pull/2577 and https://github.com/mesonbuild/meson/pull/2618.

[siriobalmelli]

I'm running into this as well - did a precise write-up and opened a separate issue so as not to hijack this thread: #3077

[ryandesign]

While using an absolute install_name would make things a bit easier in the short run, this is short-sighted and a path full of pain.

Using an absolute install_name is what every other build system normally does on macOS. It works great. It's not relocatable, but those who want relocatable binaries should run install_name_tool afterward to fix things up. What meson is currently doing does not work. Please change it. We are starting to use meson for some ports in MacPorts, and each port has to individually fix up the install_name in each of the port's libraries and binaries. We don't want to do that, and we shouldn't have to.

[mojca]

I cannot find the exact location, but someone asked me how this issues is handled in CMake.

Please take a look at a hello-world example that I have put on https://github.com/mojca/test-meson-libraries.

In short: CMake would call install_name_tool again during make install.

[jpakkane]

Based on the sample code, everyone would need to set an install_name property on all their targets. We can certainly add that but it is a bit imperfect. Is there a way to make this work correct automatically (say, 95% of the time)?

[jpakkane]

As an example we could have a new option, say, b_installname which could be set to either preserve or absolute. For the latter value, if a target does not have install_name property set, its install_name will be changed to an absolute path. Otherwise the value specified (or the default value) is used.

[SoapGentoo]

@jpakkane both CMake and libtool get it right? Set a temporary install_name and/or RPATH during build, and relink with correct absolute install_name during install?

[jpakkane]

Not relinking, direct manipulation by install_name_tool but basically yes.

[SoapGentoo]

@jpakkane this is somewhat related too: I've noticed that Meson doesn't remove RPATHs when installing, leaving the RPATHs in the binaries

[RJVB]

Using an absolute install_name is what every other build system normally does on macOS.

Isn't that what you get anyway if you don't use the install_name option but just let the toolchain figure things out?

[smancill]

Using an absolute install_name is what every other build system normally does on macOS.

Well, no. CMake uses @rpath as the install_name directory by default since CMake 3.0.

https://cmake.org/cmake/help/latest/policy/CMP0042.html

[RJVB]

And the MacPorts CMake PortGroup sets -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON

[ryandesign]

Using an absolute install_name is what every other build system normally does on macOS.

Isn't that what you get anyway if you don't use the install_name option but just let the toolchain figure things out?

No. If you don't set a library's install_name, it will be set to wherever the file is at build time (either the relative path or the absolute path to wherever the library is in the build tree, depending on how the build system specified it). Instead, it needs to be set to the absolute path of where the library will be installed.

And the MacPorts CMake PortGroup sets -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON

I don't know cmake well so I can't tell you what that does. But ports in MacPorts that build with cmake end up with their libraries' install_names set to the absolute path where they will be installed, just like ports built with most other build systems. Ports that build with @rpath in their install_names cause various issues, so we seek them out and fix them so that they do not contain @rpath anymore.

[albertjin]

Ports that build with @rpath in their install_names cause various issues, so we seek them out and fix them so that they do not contain @rpath anymore.

It makes package relocation easier when a library's install_name is prefixed by @rpath/ rather than its absolute path and the related executable has its library search as @executable_path/../lib. A build tool should support this feature.

If meson does not support this feature, it just means that there is a limitation in the build tool. It can be simply fixed by install_name_tool with extra effort. It smells bad of meson.

[RJVB]

On Sunday March 26 2023 01:37:54 Albert Jin wrote:

Ports that build with @.in theirinstall_name`s cause various issues, so we seek them out and fix them so that they do not contain @.anymore. [...] Ifmesondoes not support this feature, it just means that there is a limitation in the build tool. It can be simply fixed byinstall_name_toolwith extra effort. It smells bad ofmeson`.

Just to be clear: the "Ports that build with..." quote came from a MacPorts developer. MacPorts uses the principle that all libraries are expected to be in their designated locations so that the presence of another version or variant of that same library in a different location cannot lead to problems. That's another use case and I think we agree on the fact that build tools should enable freedom of choice in this matter rather than preach what it considers official gospel.

[eli-schwartz]

Would someone like to submit a proposal in PR form, that adds a configure time option for this? It seems like a reasonable thing to accept...