dbus linked with libglib by default
Thiago Macieira
thiago at kde.org
Thu Sep 21 09:26:49 PDT 2006
frederic heem wrote:
>> 1) only one developer ever worked on it and, in the end, the project
>> died because he didn't have the time anymore
>> 2) KDE started requiring the last version that didn't link to glib
>
>Just because one kde project linked with glib died doesn't mean that kde
> can no longer depends on glib.
We're not talking about one KDE sub-project depending on glib. We're
talking about the whole KDE doing so.
And my intention here was to illustrate what happened in the past. And
what you can expect as a reaction if you propose this to the KDE
developer community.
>> >Anyway glib will be linked to Qt by default.
>>
>> Huh? glib will link to Qt?
>
>[root at heefre lib]# ldd libQtCore.so
> linux-gate.so.1 => (0x0089e000)
> libz.so.1 => /usr/lib/libz.so.1 (0x00111000)
> libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00e6a000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x00124000)
> libdl.so.2 => /lib/libdl.so.2 (0x00be7000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00138000)
> libm.so.6 => /lib/libm.so.6 (0x00225000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0024a000)
> libc.so.6 => /lib/libc.so.6 (0x00256000)
> /lib/ld-linux.so.2 (0x0089f000)
That's Qt linking to glib (not the other way around). And, as I said, it's
optional.
$ ldd libQtCore.so
linux-gate.so.1 => (0xbfffe000)
libz.so.1 => /lib/libz.so.1 (0xb7e2e000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7e1b000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e17000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d33000)
libm.so.6 => /lib/i686/libm.so.6 (0xb7d0d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d02000)
libc.so.6 => /lib/i686/libc.so.6 (0xb7bd5000)
/lib/ld-linux.so.2 (0x80000000)
>> You've completely forgotten of the people who don't use glib now. By
>> linking to it, you increase the binary size for them.
>
>You mean people who are using dynamically typed language such as perl
> and python ? These person do not care at all about memory footprint or
> runtime speed, so add a 500 kb library won't hurt.
Ok, just to give you one example: Qtopia users. They have limited memory
available, in PDAs and in cellphones. They don't use glib now. By making
libdbus-1 use it, you increase the binary size for them.
Another argument is that, as other people have said, it's not a simple
matter of replacing one code with another. There's a lot of work to be
done to integrate that. It's a lot of man-hours spent doing something
that may be otherwise unneeded.
>> But trust me on the religious argument: don't go there. Just kill this
>> idea right now.
>
>Only technical arguments interests me, religious arguments are for
> morons.
Whatever your point in religious arguments, you cannot avoid them: it'll
be so overwhelming that it'll deafen any technical discussion. Not to
mention a lot of bad publicity being generated from both sides (in favour
and against the linking).
If D-Bus links to glib, we'll have a fork. Trust me on that.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060921/185f51ae/attachment-0001.pgp
More information about the dbus
mailing list