Hi! In debian, we have somewhat complicated build instructions for unbound due to two build passes, - one for the daemon itself and the support tools, and a separate pass for libunbound. In the past this was because of a few separate issues, like building for/with python2 and python3, so there were multiple build passes, but now only 2 of them left.
How it works: first, we build everything, including libunbound.so & libunbound.a, daemon and tools, next, with its own ./configure step *with different options*, we build just libunbound. And ship this libunbound from the separate configure step, and tools with the daemon from the first build step. Effectively, we replace libunbound used to build tools at step 1 with another libunbound built in step 2. To me, this seemed wrong already, since the tools expect some configuration detected by ./configure, but in fact the library is built with different configuration; but in practice, it seems, this actually works for now. Ok. I tried to build everything in one go. But this way, libunbound has more runtime dependencies than separately-built libunbound, - like, it gets additional deps from libhiredis, libnghttp, libpython, libsystemd etc, - the ones which are enabled for daemon in the build instructions but not enabled for separate libunbound build. Daemon itself is linked with the static libunbound.a by default (unless --enable-allsymbols is given to ./configure). On the other hand, libunbound.so is used by quite some other projects besides unbound tools like unbound-host etc. The question actually is: how libunbound.so is supposed to be built and used? Is it really an internal library or a public one? How about the optional features (like the above mentioned) - should these be part of the public ABI or internal to the daemon? Thanks! /mjt
