cmake: Always provide `RPATH` on NetBSD #31543

Apparently, runtime paths cannot be skipped on NetBSD, even for system-wide packages.

On NetBSD 10.0:

• on the master branch @ bb57017b2945d5e0bbd95c7f1a9369a8ab7c6fcd:

$ cmake -B build -DCMAKE_C_COMPILER="/usr/pkg/gcc14/bin/gcc" -DCMAKE_CXX_COMPILER="/usr/pkg/gcc14/bin/g++"
$ cmake --build build
$ ./build/src/bitcoin-wallet -version
./build/src/bitcoin-wallet: Shared object "libsqlite3.so.0" not found
$ cmake --install build --prefix /home/hebasto/INSTALL
$ /home/hebasto/INSTALL/bin/bitcoin-wallet -version 
/home/hebasto/INSTALL/bin/bitcoin-wallet: Shared object "libsqlite3.so.0" not found

• with this PR:

$ cmake -B build -DCMAKE_C_COMPILER="/usr/pkg/gcc14/bin/gcc" -DCMAKE_CXX_COMPILER="/usr/pkg/gcc14/bin/g++"
$ cmake --build build
$ ./build/src/bitcoin-wallet -version | head -1
Bitcoin Core bitcoin-wallet utility version v28.99.0-11115e9aa845
$ cmake --install build --prefix /home/hebasto/INSTALL
$ /home/hebasto/INSTALL/bin/bitcoin-wallet -version | head -1
Bitcoin Core bitcoin-wallet utility version v28.99.0-11115e9aa845

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31543.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Tracked in https://github.com/hebasto/bitcoin-core-nightly/issues/6.

What makes NetBSD special in this regard?

Edit: And where is your libsqlite3.so.0 that it can't find?

Edit: And where is your libsqlite3.so.0 that it can't find?

As a result of executing the pkgin install sqlite3 command, the library is installed in the /usr/pkg:

$ ls -1 /usr/pkg/lib/libsqlite*
/usr/pkg/lib/libsqlite3.a
/usr/pkg/lib/libsqlite3.la
/usr/pkg/lib/libsqlite3.so
/usr/pkg/lib/libsqlite3.so.0
/usr/pkg/lib/libsqlite3.so.0.8.6

What makes NetBSD special in this regard?

I think, it's NetBSD's philosophy.

From https://man.netbsd.org/ld.elf_so.1:

The linker will search for libraries in three lists of paths:

1.   A user defined list of paths as specified in LD_LIBRARY_PATH and
     [ld.so.conf(5)](https://man.netbsd.org/ld.so.conf.5).

     The use of ld.so.conf should be avoided as the setting of a global
     search path can present a security risk.

2.   A list of paths specified within a shared object using the DT_RPATH
     and DT_RUNPATH entries in the dynamic section.  This is defined at
     shared object link time.

3.   The list of default paths which is set to /usr/lib.

From the docs above, it follows that /usr/pkg/lib/ should be specified as a runtime path in the executable.

In fact, this is what NetBSD does for all its utilities. Compare:

• NetBSD 10.0:

$ ldd /bin/ls
/bin/ls:
	-lutil.7 => /lib/libutil.so.7
	-lc.12 => /lib/libc.so.12
$ readelf -d /bin/ls | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [/lib]

• Ubuntu 24.04:

$ ldd /usr/bin/ls
	linux-vdso.so.1 (0x00007ffdd77fd000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007842fca1f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007842fc800000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007842fc766000)
	/lib64/ld-linux-x86-64.so.2 (0x00007842fca8c000)
$ readelf -d /usr/bin/ls | grep RPATH
# nothing

So the ld finds the lib to link against, but the runtime loader then can't find it? That seems absurd.

Or is it because the toolchain you're using adds /usr/pkg/lib/ to ld's paths?

So the ld finds the lib to link against, but the runtime loader then can't find it? That seems absurd.

Or is it because the toolchain you're using adds /usr/pkg/lib/ to ld's paths?

This is because CMake uses absolute paths to libraries during the linking stage.

So the ld finds the lib to link against, but the runtime loader then can't find it? That seems absurd. Or is it because the toolchain you're using adds /usr/pkg/lib/ to ld's paths?

This is because CMake uses absolute paths to libraries during the linking stage.

Yes, but I was asking how it found it to link against in the first place.

Answering my own question: CMake is adding it, not ld.

Still seems like extremely annoying behavior, but 🤷.

utACK https://github.com/bitcoin/bitcoin/pull/31543/commits/11115e9aa845d675a88e18e729913f0aaa11e322