building libunbound together with or separate from daemon

[Michael Tokarev]

A friendly ping, anyone know answers to these questions?

07.09.2023 09:44, Michael Tokarev via Unbound-users:
> 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