Development version of BIND 9 - 9.21.10 with meson build system
Havard Eidnes
he at uninett.no
Wed Oct 1 15:26:42 UTC 2025
>> 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
More information about the bind-users
mailing list