Libraries linked to libunbound.so

[Petr Mensik]

On 10/19/2018 08:44 PM, Paul Wouters wrote:
> 
> 
> Sent from mobile device
> 
>> On Oct 19, 2018, at 6:06 PM, Anand Buddhdev via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
>>
>> 1. For the daemon package, build it with static linking
> 
> That is not allowed with fedora (for good reason I think)
Sure, static linking is wrong way to solve it. Yet we use exactly that
in our current package. unbound, unbound-checkconf, unbound-streamtcp
and unbound-control do not link dynamically to libunbound. So they are
statically linked in my opinion, sort of. I have never noticed it
before. Robert takes advantage of that in Debian I think.
> 
>>
>> 2. Build unbound with dynamic linking. For the first build, disable
>> systemd and dnstap, and package the libraries as "unbound-libs". Next,
>> build it again, with systemd and dnstap enabled, and create two
>> packages: "unbound" and "unbound-libs-heavy", and make "unbound" depend
>> on "unbound-libs-heavy".
> 
> That is indeed pretty hacky.
> 
> If the systemd software watchdog is separated from the socket activation stuff, we can include that. The socket activation makes no sense and caused unbound to crash.
> 
> Paul
> 
I would like to signal service readiness from unbound. I do not think
socket activation is useful for us. If it always crashes often or
always, it has to be fixed.

I think more clean solution would be implementing some sort of interface
in libunbound for dnstap. The interface implementation would be linked
only to server and added in library initialization. DNSTAP code is
isolated enough for it. Just a structure with 3 function pointers would
work I think. Would require moving some code and non-trivial changes.
Probably would require ABI change. Would it be considered mergeable if I
prepared some prototype?

Systemd is more integrated. I am not sure whether it is really useful
for us.

Is anyone using out-of-tree configure and build to get different
results? Is it tested and used by nlnetlabs? Even tests work from
different directory it seems. Can it be relied on? We build two time for
different python versions, more variants would make it a mess.

Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com  PGP: 65C6C973