Meson strips rpaths set via pkgconfig on install #4027
Comments
|
This issue affects SWI Prolog from Fedora 28 main repositories. |
|
Instead of stripping all RPATHs set, we could strip only the values that point to the builddir and sourcedir. I have no objections to this, since all other build systems seem to allow it, but it requires @jpakkane's approval. |
|
Meson's rpath stripping also impacts Spack (see spack/spack#10463). Spack sets rpaths for all dependencies on purpose but Meson removes them all on install. It would be nice to be able to tell Meson to leave the rpaths alone. |
|
The original bug about rpath appears to be #314, which was closed after fixing some build rpath issues (but not the install rpath issues). There are a number of related issue reports. One that gets referenced a lot is #2567. A really nice issue report for a very related issue on MacOS is #3077, which was fixed by 96b7fdb Also, if the wider issue is "meson does not support pkgconfig workflow with non-standard prefixes", |
|
The workaround I'm trying now is:
e.g. in my debian/rules, I have Finners crossed. |
|
Turns out I really do also need to inject an rpath into the .pc file as I mentioned earlier, so on Linux I'm also trying: because I don't have time for a proper kludge. |
|
I enabled the test case in question in a branch:
Applying https://raw.githubusercontent.com/MontaVista-OpenSourceTechnology/poky/f705787a07f1043d9143516cb3b9775fd758107d/meta/recipes-devtools/meson/meson/disable-rpath-handling.patch rescues it. I'm still trying to figure out if that workaround is enough here. |
By default meson will remove all RPATH data when installing software The patch the formula is fetching has been provided for fixing mesonbuild/meson#4027 which is similar to the problem linuxbrew is having as it doesn't install software in the normal path. The patch is adding a test before modifying RPATH: - if install_rpath is set, modify RPATH to install_rpath - otherwise, keep existing RPATH
|
Had a moment to write a draft fix and clean test for this use case, and extend an older related test case. |
|
Now released, https://mesonbuild.com/Release-notes-for-0-55-0.html |
The `ddprof_ffi_with_rpath.pc` includes the linker flags
`-Wl,-rpath,${libdir}` so that libddprof can be linked to and used in
the directory it gets installed to.
Without this, we would need to set the same flags in the libddprof user
side, or use `LD_LIBRARY_PATH` or some other mean to tell the OS how
to find libddprof.
These two links helped me figure this out:
* https://amir.rachum.com/blog/2016/09/17/shared-libraries/
* mesonbuild/meson#4027
Also included is a change to `ffi-build.sh` so that the macOS dynamic
library is setup to correctly being used with rpath.
… macOS (#26) * Upgrade to latest version of `standard` gem * Cleanup old versions from Rakefile We don't support using an up-to-date `Rakefile` to release a version other than the current in `version.rb` so it doesn't make sense to keep old versions around. * Avoid packaging a few more useless files * Refactor `Rakefile` to avoid repetition, add experimental support for macOS * Add mechanism to exclude some libddprof tarball files from package * Package libddprof shared library only, ignore static library This is still WIP, since the 0.3.0 release doesn't actually ship a shared library. * Code reformatter fixes * Tweak experimental macOS packaging * Add pkg-config variant that sets rpath The `ddprof_ffi_with_rpath.pc` includes the linker flags `-Wl,-rpath,${libdir}` so that libddprof can be linked to and used in the directory it gets installed to. Without this, we would need to set the same flags in the libddprof user side, or use `LD_LIBRARY_PATH` or some other mean to tell the OS how to find libddprof. These two links helped me figure this out: * https://amir.rachum.com/blog/2016/09/17/shared-libraries/ * mesonbuild/meson#4027 Also included is a change to `ffi-build.sh` so that the macOS dynamic library is setup to correctly being used with rpath.
… macOS (#26) * Upgrade to latest version of `standard` gem * Cleanup old versions from Rakefile We don't support using an up-to-date `Rakefile` to release a version other than the current in `version.rb` so it doesn't make sense to keep old versions around. * Avoid packaging a few more useless files * Refactor `Rakefile` to avoid repetition, add experimental support for macOS * Add mechanism to exclude some libddprof tarball files from package * Package libddprof shared library only, ignore static library This is still WIP, since the 0.3.0 release doesn't actually ship a shared library. * Code reformatter fixes * Tweak experimental macOS packaging * Add pkg-config variant that sets rpath The `ddprof_ffi_with_rpath.pc` includes the linker flags `-Wl,-rpath,${libdir}` so that libddprof can be linked to and used in the directory it gets installed to. Without this, we would need to set the same flags in the libddprof user side, or use `LD_LIBRARY_PATH` or some other mean to tell the OS how to find libddprof. These two links helped me figure this out: * https://amir.rachum.com/blog/2016/09/17/shared-libraries/ * mesonbuild/meson#4027 Also included is a change to `ffi-build.sh` so that the macOS dynamic library is setup to correctly being used with rpath.
If a .pc file specifies -Wl,-rpath, it probably has a good reason to.
Thus it is surprising that meson strips those rpaths on install.
The workaround suggested by #1411
is awkward as it requires knowing what rpath the library needed.
[Edit: and it requires editing the meson config, which is awkward when
you're just trying to package, say, gstreamer to install to /opt/foo.
What's the point of meson's --prefix option if it forbids rpaths pointing into that prefix?]
Since rpath in .pc files are frowned upon in linux distributions, this is likely to only
affect third-party software that installs libraries to /opt.
If meson is making a policy statement that .pc files must not contain rpath options, it should say so clearly, and possibly abort when such .pc files are encountered
The text was updated successfully, but these errors were encountered: