>> Surely that RPATH is wrong, the first component should have been >> "$ORIGIN/../lib/", no? > > No, not really. This is just a weird NetBSD quirk that its > dynamic linker can't be configured and requires RPATH for > everything. > > The $ORIGIN/ is needed, so the built binaries can be executed from > the build directory even without installing them.
BTW, I changed to testing with BIND 9.21.12, I think that was an earlier hint. I think I have a bit more cogent feedback on the point about the RPATH now. I still think this rpath in the installed dig executable is wrong: Dynamic section at offset 0x408600 contains 33 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libdns-9.21.12.so] 0x0000000000000001 (NEEDED) Shared library: [libisc-9.21.12.so] 0x0000000000000001 (NEEDED) Shared library: [libisccfg-9.21.12.so] 0x0000000000000001 (NEEDED) Shared library: [libidn2.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.12] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/:/usr/pkg/lib] The reason goes as follows: In the build directory set up by meson, the executables (dig among them) and the shared libraries are left in the same directory. In that case it makes perfect sense to use $ORIGIN/ to refer to where the shared libraries for the "dig" executable should be looked for, since the build directory is the $ORIGIN of the dig executable. However, after the install is done, dig is placed in $PREFIX/bin, while the shared libraries are put in $PREFIX/lib, i.e. different directories. The $ORIGIN for the installed 'dig' will be $PREFIX/bin, and you will not find the shared libraries which dig depends on in that directory. Instead, you need to refer to $ORIGIN/../lib/. Therefore, the rpath needs to be updated / changed at the latest in the install phase. BTW, with some help, I found the reason for $ ldd /usr/local/bin/dig ldd: /usr/local/bin/dig: invalid ELF class 2; expected 1 $ and a workaround for the problem that NetBSD 10.1's ld.elf_so refuses to have anything to do with libdns-9.21.12.so: With ld.elf_so compiled with DEBUG and LD_DEBUG set in the environment, attempts at executing dig out of the build directory is met with _rtld_error: /usr/local/src/bind-9.21.12/build-dir/.//libdns-9.21.12.so: wrong number of segments (4 != 2) Applying the change from https://mail-index.netbsd.org/source-changes/2023/01/06/msg142652.html to ld.elf_so and rebuild & re-install fixes both issues: $ ./dig xxxxxx.no. a +short $ echo $? 0 $ and $ pwd /usr/local/src/bind-9.21.12/build-dir $ ldd ./dig ./dig: -ldns-9.21.12 => /usr/local/src/bind-9.21.12/build-dir/.//libdns-9.21.12.so -lisc-9.21.12 => /usr/local/src/bind-9.21.12/build-dir/.//libisc-9.21.12.so -lnghttp2.14 => /usr/pkg/lib/libnghttp2.so.14 -lc.12 => /usr/lib/libc.so.12 -lm.0 => /usr/lib/libm.so.0 -lcrypto.15 => /usr/lib/libcrypto.so.15 -lcrypt.1 => /lib/libcrypt.so.1 -lssl.15 => /usr/lib/libssl.so.15 -lurcu-common.8 => /usr/pkg/lib/liburcu-common.so.8 -lpthread.1 => /usr/lib/libpthread.so.1 -lurcu.8 => /usr/pkg/lib/liburcu.so.8 -luv.1 => /usr/pkg/lib/libuv.so.1 -lkvm.6 => /usr/lib/libkvm.so.6 -ljson-c.5 => /usr/pkg/lib/libjson-c.so.5 -lxml2.16 => /usr/pkg/lib/libxml2.so.16 -lz.1 => /usr/lib/libz.so.1 -llzma.2 => /usr/lib/liblzma.so.2 -lurcu-cds.8 => /usr/pkg/lib/liburcu-cds.so.8 -lfstrm.0 => /usr/pkg/lib/libfstrm.so.0 -lprotobuf-c.1 => /usr/pkg/lib/libprotobuf-c.so.1 -lmaxminddb.0 => /usr/pkg/lib/libmaxminddb.so.0 -lgssapi.12 => /usr/lib/libgssapi.so.12 -lkrb5.28 => /usr/lib/libkrb5.so.28 -lhx509.7 => /usr/lib/libhx509.so.7 -lasn1.10 => /usr/lib/libasn1.so.10 -lcom_err.8 => /usr/lib/libcom_err.so.8 -lroken.20 => /usr/lib/libroken.so.20 -lutil.7 => /usr/lib/libutil.so.7 -lwind.1 => /usr/lib/libwind.so.1 -lheimbase.2 => /usr/lib/libheimbase.so.2 -lheimntlm.6 => /usr/lib/libheimntlm.so.6 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 -lisccfg-9.21.12 => /usr/local/src/bind-9.21.12/build-dir/.//libisccfg-9.21.12.so -lns-9.21.12 => /usr/local/src/bind-9.21.12/build-dir/.///libns-9.21.12.so -lidn2.0 => /usr/pkg/lib/libidn2.so.0 -lunistring.5 => /usr/pkg/lib/libunistring.so.5 -lintl.1 => /usr/lib/libintl.so.1 $ This points to there now being quite a long time since the NetBSD 10.x release branch was created... However, my claim that the RPATH for the dig executable when installed in /usr/local/bin is wrong still stands, because of $ ldd /usr/local/bin/dig /usr/local/bin/dig: -ldns-9.21.12 => not found -lisc-9.21.12 => not found -lisccfg-9.21.12 => not found -lidn2.0 => /usr/pkg/lib/libidn2.so.0 -lunistring.5 => /usr/pkg/lib/libunistring.so.5 -lc.12 => /usr/lib/libc.so.12 -lintl.1 => /usr/lib/libintl.so.1 -lpthread.1 => /usr/lib/libpthread.so.1 $ If I doctor the rpath with # patchelf --print-rpath /usr/local/bin/dig $ORIGIN/:/usr/pkg/lib # patchelf --force-rpath --set-rpath '$ORIGIN/../lib/:/usr/pkg/lib' /usr/local/bin/dig # patchelf --print-rpath /usr/local/bin/dig $ORIGIN/../lib/:/usr/pkg/lib # it finds all the required shared libraries: $ ldd /usr/local/bin/dig /usr/local/bin/dig: -ldns-9.21.12 => /usr/local/bin/../lib//libdns-9.21.12.so -lisc-9.21.12 => /usr/local/bin/../lib//libisc-9.21.12.so -lnghttp2.14 => /usr/pkg/lib/libnghttp2.so.14 -lc.12 => /usr/lib/libc.so.12 -lm.0 => /usr/lib/libm.so.0 -lcrypto.15 => /usr/lib/libcrypto.so.15 -lcrypt.1 => /lib/libcrypt.so.1 -lssl.15 => /usr/lib/libssl.so.15 -lurcu-common.8 => /usr/pkg/lib/liburcu-common.so.8 -lpthread.1 => /usr/lib/libpthread.so.1 -lurcu.8 => /usr/pkg/lib/liburcu.so.8 -luv.1 => /usr/pkg/lib/libuv.so.1 -lkvm.6 => /usr/lib/libkvm.so.6 -ljson-c.5 => /usr/pkg/lib/libjson-c.so.5 -lxml2.16 => /usr/pkg/lib/libxml2.so.16 -lz.1 => /usr/lib/libz.so.1 -llzma.2 => /usr/lib/liblzma.so.2 -lurcu-cds.8 => /usr/pkg/lib/liburcu-cds.so.8 -lfstrm.0 => /usr/pkg/lib/libfstrm.so.0 -lprotobuf-c.1 => /usr/pkg/lib/libprotobuf-c.so.1 -lmaxminddb.0 => /usr/pkg/lib/libmaxminddb.so.0 -lgssapi.12 => /usr/lib/libgssapi.so.12 -lkrb5.28 => /usr/lib/libkrb5.so.28 -lhx509.7 => /usr/lib/libhx509.so.7 -lasn1.10 => /usr/lib/libasn1.so.10 -lcom_err.8 => /usr/lib/libcom_err.so.8 -lroken.20 => /usr/lib/libroken.so.20 -lutil.7 => /usr/lib/libutil.so.7 -lwind.1 => /usr/lib/libwind.so.1 -lheimbase.2 => /usr/lib/libheimbase.so.2 -lheimntlm.6 => /usr/lib/libheimntlm.so.6 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 -lisccfg-9.21.12 => /usr/local/bin/../lib//libisccfg-9.21.12.so -lns-9.21.12 => /usr/local/bin/../lib///libns-9.21.12.so -lidn2.0 => /usr/pkg/lib/libidn2.so.0 -lunistring.5 => /usr/pkg/lib/libunistring.so.5 -lintl.1 => /usr/lib/libintl.so.1 $ "Rinse and repeat for all the other executables." So this indicates that rpath should be different for "built for use directly from the build directory" and "built for the final installation destination" executables. And ... if possible, the build of the executables for the "built for the final installation destination" could just as well directly use the known location of the destination for the shared libraries instead of relying on $ORIGIN. Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
