> I get so negative vibes from your comments. Why? I'm just trying to solve > problems here, and they're not all of my own making.
There are no negative nor positive vibes. I’m just saying that if a operating system or its flavor decides that its dynamic linking system deviates from the industry standard (for whatever reason), it should be the responsibility of the operating system to make things work with ubiquitous build systems (autotools, cmake, and now meson). I will be happy to review and accept patches to help with the effort to build on NetBSD, but it is not BIND 9’s responsibility to make this work. And ultimately any NetBSD quirks should be brought to meson upstream, so all projects using it would benefit from this. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 15. 1. 2026, at 14:28, Havard Eidnes <[email protected]> wrote: > > Following up on an Old message, while trying to get BIND 9.21.14 > to build & work on my system: > >> Add >> -Dc_link_args=-Wl,-rpath='$ORIGIN/../lib' >> -Dc_link_args=-Wl,-z,noseparate-code >> >> to meson invocation. This might get you going. > > That's actually wrong. The latter -D will override the former, > and the rpath adjustment is therefore ignored. By the looks of > it they need to be specified with one -D, like so: > > -Dc_link_args='-Wl,-rpath=$ORIGIN/../lib -Wl,-z,noseparate-code' > > So the recipe for building and installing using "build-dir" as > the build dir on NetBSD with sufficiently new ld.elf_so: > > meson setup build-dir \ > -Dtracing=disabled \ > -Dc_link_args='-Wl,-rpath=$ORIGIN/../lib -Wl,-z,noseparate-code' > meson compile -C build-dir > meson install -C build-dir > > (The turning off tracing is for dtrace support which if left > enabled ends up with lots of undefined symbols. I think I asked > where those were supposed to come from, but got no response to > that question.) > >> So, far, I am not seeing "NetBSD quirks", but broken base >> system with linker (ld) allowing options that are broken and a >> broken dynamic linker. This has nothing to do with BIND 9 and >> needs to be fixed in NetBSD directly. Also if the base system >> doesn't include /usr/local/lib, it probably should add >> $ORIGIN/../lib to rpath by default and not rely on applications >> to do that because ... reasons. > > I get so negative vibes from your comments. Why? I'm just > trying to solve problems here, and they're not all of my own > making. > > As for not including /usr/local/lib in the RPATH by default > actually stems from security concerns. Someone might have more > relaxed permissions for that lib directory than for "system > directories", and being able to trick programs into loading a > rogue .so would be bad. > > Also, pkgsrc frowns on (and removes!) the use of $ORIGIN, for > somewhat of the same reasons: a binary may be moved, and the > neighboring ../lib directory might be abused. RPATH must > therefore be explicitly specified, could be done via $PREFIX > which is expanded at build time. > > Regards, > > - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
