dbus-daemon statically linked with libdbus-1?

[Simon McVittie]

On 04/06/14 20:23, Colin Walters wrote:
>> 2) the daemon uses the private API from libdbus-1, which is not exported.
>> It's 
>> simply not possible to link the daemon to the standard library.
> 
> This however is quite a valid reason it's statically linked right now =)

Let me turn this around. Why do you want it not to be statically linked?
The usual reasons for wanting to avoid static linking are on-disk size,
in-memory size, and security updates.

Disk size:

On my x86-64 Debian laptop, the shared libdbus is 280K. All the dbus-*
tools are linked to it dynamically, except for dbus-daemon (408K) and
dbus-daemon-launch-helper (280K). So the most you could possibly save
like this would be to cut up to 280K each off the on-disk size of
dbus-daemon and d-d-l-h (in practice it'll be less, because I'm sure
they don't use all of libdbus). Sure, that would be an improvement, but
I'm not sure the cost/benefit ratio is significant (particularly if
dynamic linking overhead eats up some of the benefit).

In-memory size:

dbus-daemon-launch-helper is short-lived, so its impact on memory size
is insignificant. As for dbus-daemon, I'm not sure whether multiple
instances of the same binary share the memory used for their code. If
they do, you gain nothing. If they don't, assuming the in-memory size is
similar to the size of the binary, you could save up to about 300K per
user. Again, I'm not convinced by the cost/benefit ratio here :-)

Security updates if there is a vulnerability in libdbus:

libdbus, dbus-daemon and d-d-l-h come from the same source package, so
even if they are in separate binary packages/RPM subpackages (as they
usually are), I would expect any sensible distribution to do
all-or-nothing updates for those packages in any case; the usual
static-linking issue of "avoid having to update 100 copies of zlib" does
not apply here.

> Alternatives though:
> 
> 1) Split out a the private bits into /usr/lib64/dbus-1/dbus-private.so

There are three layers of API:

a) utility functionality, analogous to GLib
b) public API for applications
c) stuff that's used by dbus-daemon and dbus-daemon-launch-helper
   (*-util.c)

libdbus-1.so.3 contains (b) so applications can use it, and (a) because
the implementation of (b) needs (a).

libdbus-internal.a (the convenience library that is linked into the
dbus-daemon and d-d-l-h) additionally contains (c), which does not have
the same requirements as (a) and (b) - in particular it doesn't need to
be thread-safe.

(a) and (c) are considered private, and function names start with _dbus
instead of dbus.

I don't want to split libdbus-1.so.3 into three shared libraries: that's
much more complicated than we need.

> 2) Have the shared library export a single dbus__private() API which
> returns
>   a structure of function pointers. Like:
> https://git.gnome.org/browse/glib/commit/?id=9bf59d4a14b3fc4bb62f10c3665e99f9d8788bdc

This sounds far more complicated than it's worth. (a) is quite large,
and includes basic "make C not horrible" features like linked lists and
hash tables - I don't want to indirect all those through a vtable.

Using versioned symbols is a possibility. We could version (a) as
LIBDBUS_PRIVATE_1.9.0 (or whatever), keeping the underscore prefix as an
additional hint to applications that this functionality is really not
for them; version (b) as LIBDBUS_1_3; and change (c) to be a static
library (or a private shared library) that depends on libdbus-1.so.3.

I don't think there's necessarily any point in making (c) into a shared
library: the vast majority of it is only used by dbus-daemon, so no disk
or memory space would actually be saved, at the cost of bringing in more
dynamic linker overhead. It's also used by some of the regression tests,
but those are irrelevant to production systems.

    S