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) [email protected] 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 > <[email protected]> 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. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
