building libunbound together with or separate from daemon

[Michael Tokarev]

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