Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop. V
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
GNOME v. KDE, December 2005 edition
GNOME v. KDE, December 2005 edition
Posted Dec 13, 2005 18:57 UTC (Tue) by hazelsct (subscriber, #3659)In reply to: GNOME v. KDE, December 2005 edition by erwbgy
Parent article: GNOME v. KDE, December 2005 edition
Bzzzt! Wrong answer. Qt license costs are trivial compared to developer time, except perhaps in India or China.
The real issue is the annual -- and always "final" -- change of the C++ ABI which breaks every binary app linked to C++ libs. In contrast, one can write against the GNOME 2.0 ABI and be guaranteed nearly five years of stability. As long as this keeps up, corporate developers will continue to stay away from KDE, Qt, and all other projects whose infrastructure libs are written in C++.
Linux, the GNU toolchain, X, GTK, GNOME, all one big happy C family!
(Log in to post comments)
GNOME v. KDE, December 2005 edition
Posted Dec 13, 2005 20:37 UTC (Tue) by nix (subscriber, #2304) [Link]
Parts of X, specifically Mesa, are written in C++.
GNOME v. KDE, December 2005 edition
Posted Dec 13, 2005 23:38 UTC (Tue) by airlied (subscriber, #9104) [Link]
libGLU is the only major C++ component in Mesa and it provides only a C ABI... so doesn't have any of these issues...
I think some shader code recently added might be in C++ but again no ABI...
GNOME v. KDE, December 2005 edition
Posted Dec 14, 2005 7:23 UTC (Wed) by nix (subscriber, #2304) [Link]
Hm, true. I hadn't noticed that none of the C++ness gets exported. The ABI problems will still be present with respect to libstdc++ itself, unless libGLU is linked with -Bgroup, which is a) unsupported and b) doesn't seem to be the case. (A good thing too: linking libstdc++ to *anything* with -Bgroup gives me the willies.)