cmake: Always provide `RPATH` on NetBSD

hebasto commented at 7:37 pm on December 19, 2024: member

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

On NetBSD 10.0:

on the master branch @ bb57017b2945d5e0bbd95c7f1a9369a8ab7c6fcd:

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

with this PR:

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

cmake: Always provide `RPATH` on NetBSD 11115e9aa8

hebasto added the label Build system on Dec 19, 2024

DrahtBot commented at 7:37 pm on December 19, 2024: contributor

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

Code Coverage & Benchmarks

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

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	theuni

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

hebasto commented at 7:55 pm on December 19, 2024: member

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

theuni commented at 8:04 pm on December 19, 2024: member

What makes NetBSD special in this regard?

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

hebasto commented at 9:59 pm on December 19, 2024: member

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:

0$ ls -1 /usr/pkg/lib/libsqlite*
1/usr/pkg/lib/libsqlite3.a
2/usr/pkg/lib/libsqlite3.la
3/usr/pkg/lib/libsqlite3.so
4/usr/pkg/lib/libsqlite3.so.0
5/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:

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

Ubuntu 24.04:

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

theuni commented at 6:23 pm on December 20, 2024: member

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?

hebasto commented at 6:25 pm on December 20, 2024: member

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.

theuni commented at 6:36 pm on December 20, 2024: member

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 🤷.

theuni approved

theuni commented at 6:36 pm on December 20, 2024: member

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

fanquake merged this on Jan 17, 2025

fanquake closed this on Jan 17, 2025

hebasto deleted the branch on Jan 17, 2025

hebasto referenced this in commit 7101ef975e on Jan 17, 2025

cmake: Always provide RPATH on NetBSD #31543

Code Coverage & Benchmarks

Reviews

cmake: Always provide `RPATH` on NetBSD #31543