Development version of BIND 9 - 9.21.10 with meson build system
Ondřej Surý
ondrej at isc.org
Thu Sep 25 11:55:58 UTC 2025
Hi Havard,
you are the one who probably knows how to report this, so I am asking if
you can make a magic to upgrade the userspace-rcu to something that's
not five years old and outdated in the pkgin/pkgsrc?
Otherwise, this should be the correct procedure:
1. Install userspace-rcu from git (as 0.12.1 is bit broken)
2. Configure BIND 9
LDFLAGS="$ORIGIN/../lib" PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH meson setup build --wipe -Dtracing=disabled -Dnamed-lto=off
> 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.
3. Build
> It's as if the new build system tries Really Hard to keep all the
> cards it holds hidden from anyone else trying to figure out what
> it has *actually* done.
No, simply adding -v spits out everything. That's same with the autotools
based build system. By default, it is also not verbose.
meson compile -C build -v
4. Install
You can first verify what is going to do with:
meson install -C build --dry-run
Then install:
meson install -C build -v
But then the dynamic linker fails to find the library anyway:
$ /usr/local/bin/dig
/usr/local/bin/dig: Shared object "libdns-9.21.13-dev.so" not found
To further address your comments:
> So instead ld.elf_so doesn't find the above mentioned shared
> libraries in /usr/local/lib, but instead is picking up the shared
> libraries for BIND 9.20.13 which I have installed in the /usr/pkg
> prefix, and hilarity ensues as above.
No, that's not happening, unless you mangled something. All the
libraries have properly versioned SONAMES:
$ readelf -a /usr/local/lib/libdns-9.21.13-dev.so | grep SONAME
0x000000000000000e (SONAME) Library soname: [libdns-9.21.13-dev.so]
> Hints on where to look appreciated. (I hate debugging these sort
> of problems using system call tracing...)
NetBSD dynamic linker is kind of broken? I don't really see anything wrong with this:
$ readelf -d /usr/local/lib/libisc-9.21.13-dev.so
Dynamic section at offset 0x426150 contains 34 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libnghttp2.so.14]
0x0000000000000001 (NEEDED) Shared library: [libm.so.0]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.15]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.15]
0x0000000000000001 (NEEDED) Shared library: [liburcu-common.so.9]
0x0000000000000001 (NEEDED) Shared library: [liburcu.so.9]
0x0000000000000001 (NEEDED) Shared library: [libuv.so.1]
0x0000000000000001 (NEEDED) Shared library: [libxml2.so.16]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.12]
0x000000000000000e (SONAME) Library soname: [libisc-9.21.13-dev.so]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/pkg/lib:/usr/local/lib]
0x000000000000000c (INIT) 0x200000
0x000000000000000d (FINI) 0x271cb0
0x0000000000000004 (HASH) 0x2a8
0x0000000000000005 (STRTAB) 0x9bd8
0x0000000000000006 (SYMTAB) 0x2660
0x000000000000000a (STRSZ) 25447 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x6263b0
0x0000000000000002 (PLTRELSZ) 20376 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x149a0
0x0000000000000007 (RELA) 0x10950
0x0000000000000008 (RELASZ) 16464 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x0000000000000018 (BIND_NOW)
0x000000006ffffffb (FLAGS_1) Flags: NOW
0x000000006ffffffe (VERNEED) 0x10910
0x000000006fffffff (VERNEEDNUM) 2
0x000000006ffffff0 (VERSYM) 0xff40
0x000000006ffffff9 (RELACOUNT) 638
0x0000000000000000 (NULL) 0x0
This as well:
$ readelf -d /usr/local/bin/dig
Dynamic section at offset 0x408600 contains 33 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libdns-9.21.13-dev.so]
0x0000000000000001 (NEEDED) Shared library: [libisc-9.21.13-dev.so]
0x0000000000000001 (NEEDED) Shared library: [libisccfg-9.21.13-dev.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/../lib:$ORIGIN/:/usr/pkg/lib:/usr/local/lib]
0x000000000000000c (INIT) 0x200000
0x000000000000000d (FINI) 0x21b7f0
0x0000000000000019 (INIT_ARRAY) 0x608538
0x000000000000001b (INIT_ARRAYSZ) 16 (bytes)
0x000000000000001a (FINI_ARRAY) 0x608548
0x000000000000001c (FINI_ARRAYSZ) 16 (bytes)
0x0000000000000004 (HASH) 0x2f0
0x0000000000000005 (STRTAB) 0x2d60
0x0000000000000006 (SYMTAB) 0xc90
0x000000000000000a (STRSZ) 5674 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x608850
0x0000000000000002 (PLTRELSZ) 5544 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x4c38
0x0000000000000007 (RELA) 0x4668
0x0000000000000008 (RELASZ) 1488 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x0000000000000018 (BIND_NOW)
0x000000006ffffffb (FLAGS_1) Flags: NOW PIE
0x000000006ffffffe (VERNEED) 0x4648
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x438a
0x000000006ffffff9 (RELACOUNT) 51
0x0000000000000000 (NULL) 0x0
Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org
My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
> On 25. 9. 2025, at 12:09, Havard Eidnes via bind-users <bind-users at lists.isc.org> wrote:
>
> An update after finally having installed BIND 9.21.10 in
> /usr/local on this host:
>
> $ dig xxxxxx.no. ns
> dig: Undefined PLT symbol "isc__lib_initialize" (symnum = 12)
> $ type dig
> dig is a tracked alias for /usr/local/bin/dig
> $ ldd /usr/local/bin/dig
> ldd: /usr/local/bin/dig: invalid ELF class 2; expected 1
> $ file /usr/local/bin/dig
> /usr/local/bin/dig: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 10.1, with debug_info, not stripped
> $ readelf -a /usr/local/bin/dig | less
>
> reveals among other things:
>
> Dynamic section at offset 0x408600 contains 33 entries:
> Tag Type Name/Value
> 0x0000000000000001 (NEEDED) Shared library: [libdns.so]
> 0x0000000000000001 (NEEDED) Shared library: [libisc.so]
> 0x0000000000000001 (NEEDED) Shared library: [libisccfg.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]
>
> Surely that RPATH is wrong, the first component should have been
> "$ORIGIN/../lib/", no?
>
> So instead ld.elf_so doesn't find the above mentioned shared
> libraries in /usr/local/lib, but instead is picking up the shared
> libraries for BIND 9.20.13 which I have installed in the /usr/pkg
> prefix, and hilarity ensues as above.
>
> Why ldd refuses to have anything to do with the "dig" binary is
> possibly a separate issue, and I do not know the answer to that
> right now. That goes back to finding out what exactly did the
> build process do to link this program to cause that effect?
>
> Hints on where to look appreciated. (I hate debugging these sort
> of problems using system call tracing...)
>
> The build log itself just says
>
> [320/348] Linking target dig
>
> and the install action is just logged as
>
> Installing dig to /usr/local/bin
>
> It's as if the new build system tries Really Hard to keep all the
> cards it holds hidden from anyone else trying to figure out what
> it has *actually* done.
>
> Regards,
>
> - Håvard
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
More information about the bind-users
mailing list