Open SoapGentoo opened 7 years ago
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).
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.
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
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.
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
.
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)?
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.
@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?
Not relinking, direct manipulation by install_name_tool
but basically yes.
@jpakkane this is somewhat related too: I've noticed that Meson doesn't remove RPATHs when installing, leaving the RPATHs in the binaries
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?
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.
And the MacPorts CMake PortGroup sets -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON
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_name
s 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_name
s cause various issues, so we seek them out and fix them so that they do not contain @rpath
anymore.
Ports that build with
@rpath
in theirinstall_name
s 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
.
On Sunday March 26 2023 01:37:54 Albert Jin wrote:
Ports that build with @.
in their
install_name`s cause various issues, so we seek them out and fix them so that they do not contain @.anymore. [...] If
mesondoes not support this feature, it just means that there is a limitation in the build tool. It can be simply fixed by
install_name_toolwith extra effort. It smells bad of
meson`.
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.
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...
Description
Meson's
RPATH
andinstall_name
handling are currently broken on macOS. Here's a toy example. Letfoo
be the library (aka the provider) and letbar
be the executable (aka the consumer). For foo we have: foo.cpp:foo.hpp:
meson.build:
For bar we have: bar.cpp:
meson.build:
How to reproduce
in foo (the
rm -r build
at the end is crucial to reproduce the issue):in bar:
which then greets you with a message:
The actual problem
The culprit is how meson builds libraries on macOS. The linking line is currently:
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 runotool -l
on the library you getwhere 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 runningrm -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, whereRPATH
/RUNPATH
are purely a consumer problem, the provider does not have to know about consumers'RPATH
behaviour. Thus, in order forRPATH
to work for consumers, theinstall_name
has to be@rpath/<libname>.dylib
. In a quick and hacky way, doing this infoo
:And then in bar (notice the missing colon
:
after-Wl,-rpath,
):and then
./bar
gives meConclusion
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:-install_name @rpath/<libname>.dylib
unconditionally, purely to be consumed in anRPATH
-capable way. While using an absoluteinstall_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 absoluteinstall_name
s:RPATH
-based builds are relocatable.RPATH
s 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/