cmake: Always provide RPATH on NetBSD #31543

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

2. cmake: Always provide `RPATH` on NetBSD 11115e9aa8
3. hebasto added the label Build system on Dec 19, 2024
4. 
   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.

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

   Tracked in https://github.com/hebasto/bitcoin-core-nightly/issues/6.
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?

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

8. 
   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?

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

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

11. theuni approved
12. 
    theuni commented at 6:36 pm on December 20, 2024: member

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

Contributors
hebasto DrahtBot theuni

Labels
Build system