dbus-daemon link process ...

[10function]

Hello dbus users and gurus !

I was just asking myself why the 'dbus-daemon' is not dynamically linked with 'libdbus' low-level library as shown : 

$ldd dbus-daemon
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x4001c000)
        libc.so.6 => /lib/tls/libc.so.6 (0x4003c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The link process is done as follows on my platform :
gcc -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -Wdeclaration-after-statement -fno-common -fPIC -o dbus-daemon activation.o bus.o config-parser.o connection.o desktop-file.o dir-watch-dnotify.o dispatch.o driver.o expirelist.o policy.o selinux.o services.o signals.o test.o utils.o config-loader-expat.o main.o  /usr/lib/libexpat.so ../dbus/.libs/libdbus-convenience.a

It seems that "libdbus-convenience.a" contains all exported symbols of libdbus + some internal ones (_dbus_... ) that are usefull for the daemon and this static link replace the dynamic one with libdbus. 
Well, ok that works and it's not a big deal on common platforms …but it becomes a bit annoying if you plan to port DBUS to an embedded device because of the disk space loss due to (duplicate) size of dbus-daemon + libdbus ...  

For giving an idea, i have done a quick build of a "minimalistic" DBUS environment (no asserts,no checks,no options , stripped …)
dbus-daemon is about 650Kb
libdbus is about 255Kb
libexpat is about 160Kb

==> All of this takes about 1Mb which is quite a lot for an embedded device.

What do you think of linking dynamically the dbus-daemon with libdbus ? May be this will help DBUS to play in the embedded field … ;o)

On the other hand, may be you have ideas on how to reduce build size … Please let me know . 

 Hope this helps. Thanks for all your good work.

----------------------------------------------------------------------------------------------------------------------------
Today's piece of secure software is the subject of tomorrow's Bugtraq posting


________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com