Tried using meson 78f1ef85fd6bf663b7a7d9d06f731f7ce9a6f629 to build donf.
ninja generates the correct binary:
$ objdump -x dconf-0.28.0/output/bin/dconf | more
...
Dynamic Section:
NEEDED libdconf.so.1
NEEDED libgio-2.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libc.so.12
RPATH /usr/pkg/lib:/usr/X11R7/lib
...
Then the RPATH disappears on install:
$ dconf
Shared object "libdconf.so.1" not found
$ objdump -x `which dconf` | grep -i rpath
$ ls -l /usr/pkg/lib/libdconf.so.1
lrwxr-xr-x 1 root wheel 17 Jul 9 15:05 /usr/pkg/lib/libdconf.so.1 -> libdconf.so.1.0.0
$
(running dconf-0.28.0/output/bin/dconf works)
This is intentional. The only RPATHs Meson keeps is whatever is specified in the install_rpath: kwarg to build targets.
However, perhaps we should keep RPATHs pointed to all external libraries that aren't in the default linker path. There was an old issue about this, but I can't find it anymore.
Just discovered this issue on NixOS where each library is installed to a different prefix.
Libraries found with dependency function produce the following in rpaths_for_bundled_shared_libraries:
dep = <PkgConfigDependency samplerate: True None>
la = ['/nix/store/z5fc79akswxdr2y898yb67w47ibz8kvp-libsamplerate-0.1.9/lib/libsamplerate.so']
while the ones found by compiler.find_library will just have
dep = <ExternalLibrary zita-convolver: True>
la = ['-lzita-convolver']
Since the first item in la is not absolute path, it is skipped.
Perhaps ExternalLibrary needs something similar to PkgConfigDependency.
BTW on my system:
$ objdump -x /bin/ls | more
/bin/ls: file format elf64-x86-64
/bin/ls
architecture: i386:x86-64, flags 0x00000150:
...
Dynamic Section:
NEEDED libutil.so.7
NEEDED libc.so.12
RPATH /lib
so I think the subject change to "external libraries that aren't in the default library search path" isn't the bug I was originally reporting. Is there a way of globally switching this stripping off? (and not have to change every meson using package - I didn't have to for autotools...)
The default library search path of ld.elf_so(1) in NetBSD is only /usr/lib, says the manual. If @prlw1 is running NetBSD, then none of /usr/pkg/lib, /usr/X11R7/lib, nor /lib would be in the default search path. Then "external libraries that aren't in the default library search path" might be a correct name for this bug.
Some build systems -- at least autotools and CMake -- seem to be aware of the default path, and will add other directories to the rpath. For example, I installed lhasa into ~/prefix on OpenBSD; autotools added ~/prefix/lib to the rpath so lha can load liblhasa.so.0.0:
$ objdump -x ~/prefix/bin/lha | grep RPATH
RPATH /home/kernigh/prefix/lib
If lhasa used Meson, then /home/kernigh/prefix/lib would not be in the installed rpath, so /home/kernigh/prefix/bin/lha would not run; I don't know how to fix this, unless I edit meson.build to add install_rpath: ... to the correct target.
The default path for the runtime linker can be different from the default path for the compiler. In OpenBSD, the path of ld.so(1) has /usr/lib, /usr/X11R6/lib, /usr/local/lib, and then any extra directories in shlib_dirs in rc.conf(8); the default shlib_dirs is empty. CMake's /usr/local/share/cmake/Modules/Platform/OpenBSD.cmake runs /sbin/ldconfig -r and grabs the path from the output, but the output may have hundreds of lines like
/var/run/ld.so.hints:
search directories: /usr/lib:/usr/X11R6/lib:/usr/local/lib
0:-lobjc.6.1 => /usr/local/lib/libobjc.so.6.1
1:-lpthread.22.0 => /usr/lib/libpthread.so.22.0
2:-lperl.14.0 => /usr/lib/libperl.so.14.0
...
716:-lgmp.10.0 => /usr/local/lib/libgmp.so.10.0
One might teach Meson to assume that /usr/lib:/usr/X11R6/lib:/usr/local/lib is the path on OpenBSD. Then Meson would add directories other than those 3 to the rpath. The hard part is to know the default path for a bunch of different operating systems.
Thanks for the correction: I assumed that it was /lib:/usr/lib - that would explain /bin/ls having /lib (even though those libraries are linked from /usr/lib too, so in fact that isn't strictly necessary).
In the meantime, we are using:
http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/py-meson/patches/patch-mesonbuild_minstall.py
The other patches in
http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/py-meson/patches/
provide SunOS support.
Please have a look at https://github.com/mesonbuild/meson/pull/7103
Most helpful comment
This is intentional. The only RPATHs Meson keeps is whatever is specified in the
install_rpath:kwarg to build targets.However, perhaps we should keep RPATHs pointed to all external libraries that aren't in the default linker path. There was an old issue about this, but I can't find it anymore.