Uh, okay, why?
Because the upstream devs work on distros that like to use the dbus-daemon in their startup process (i.e. upstart) and such. Which means /usr/lib/libdbus.so isn't available. And they also stick it on initramfs's
Okay, is there any opt-in to get it to NOT build it statically?
Is there any particular reason why this is such a horrible thing?
Because it duplicates code on disk and memory for no reason at all? We don't need it in /bin do we? Then why should we link it statically? libdbus as a 252KB text size, which is not exactly tiny on embedded systems and already a nuisance on my system with three dbus-daemon processes running.
As you can see in dbus/Makefile.am, there is "-export-symbols-regex "^[^_].*" option specified for building libdbus-1.so. With this option enabled, dbus-daemon can't link with shared library properly because it uses _dbus_* functions which, as Makefile commentary states, are "for internal symbols". So we have 3 options: either link dbus-daemon statically (as it is now) or export internal library symbols (which is not a good thing regarding incapsulation and security concerns), or re-writing dbus-daemon from scratch for pure libdbus-1.so interface :) So I think we can't do much with the problem. Comments?
(In reply to comment #5) > As you can see in dbus/Makefile.am, there is "-export-symbols-regex "^[^_].*" > option specified for building libdbus-1.so. With this option enabled, > dbus-daemon can't link with shared library properly because it uses _dbus_* > functions which, as Makefile commentary states, are "for internal symbols". So With this, I think it's safe to close this as CANTFIX.
