KDE/kdelibs

[Thiago Macieira]

nf2 wrote:
>Leo Savernik wrote:
>> Am Dienstag, 3. April 2007 schrieb Thiago Macieira:
>>> I don't link to those. I build Qt without glib support.
>>>
>>> I don't even have libgcc_d anywhere in my system. libgcc_s is listed
>>> there, though.
>>
>> But the typical user will face the additional penalty of the above
>> three libs. Your stats make the situation look better than it will be
>> for the majority :-(

Well, no, since libgcc_d isn't typical. In 10 years of Linux, this is the 
first time I've heard of it.

Also, glib is an optional dependency for Qt. We in no way require it in 
KDE. (And you can imagine the flame war that would be caused by requiring 
it)

Next, the point wasn't to show that libkdecore links now to 16 or 19. It 
was to show that we link to 18 libraries less -- and heavy libraries at 
that.

>is it the number of libraries or rather the number of symbols which is
>relevant for loading performance?

Both. I don't have the exact numbers (read Ulrich Drepper's "How to write 
a DSO" paper for more info), but I remember the cost being a 
multiplication of the number of libraries and the number of symbols.

>objdump -T /usr/lib/libqt-mt.so.3 | wc -l
>26086

That's Qt 3. That's completely off-topic for this thread.

Qt3 on Unix doesn't use symbol visibility nor does it reduce its 
relocation count. It's also a big library doing everything. It's 
completely opposite to the gains we've had in Qt 4.

I don't see where you're going with your numbers.

-- 
  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://mail.kde.org/pipermail/kde-core-devel/attachments/20070404/33c5dec1/attachment.sig>