Continues the odyssey of the visibility support in KDE. What is the visibility support? Well roughly is a way to tell the compiler to hide, from the resulting library, all the non-exported methods and classes, to reduce the amount of symbols exported in the public ABI. This makes the library smaller, as there are less symbol inscribed in it, and should also make it faster to load.
Good, eh? Unfortunately this is not so simple to manage.
The famous visibility support was going to be added with GCC 4, but on KDE everything was disposed for 3.4 branch so that the visibility was already enabled when present. Why doing so, if GCC 3 does not support it? Well many distributions, like Fedora, SuSE and Gentoo, used a patched GCC which added support for visibility, so what was decided was to use this support when present.
Fine, going to test that… and Marcus and me find out that KAsteroids crashed because of visibility. One of the Qt classes used for events had different RTTI information when inside KAsteroids and when inside libqt, and that was caused by Qt not exporting all of its classes.
Okay Gentoo disabled visibility support from KDE 3.4, and it was decided that Qt needed to be patched. 3.3.5 was expected to be safe from this point of view. It was not. Yeah OK, users needs to wait for Qt then, but with that patch, It Surely Works! … yeah sure, keep on trying …
With KDE 3.5_beta1, I was “forced” to try the visibility support in arts for an error in kde eclass. Okay fine, the problem turned out to be in GCC, as up to 4.0.2 libstdc++ is not safe to work with visibility enabled, 4.0.3 should be fixed, and Fedora and SuSE backported some patches that would have let it work fine, with those It Surely Works! … yeah sure, keep on fscking trying …
GCC 4.0.2-r1 had the Fedora patches included, built it and built all of KDE with the visibility enabled. I had a little problem in the middle of the build as Kooka refused to build. Still not cleared if it was a problem related to visibility, a local problem, or if it was some dep still not recompiled that fscked up its build. Okay, let’s ignore this side problem, as now Kooka is built. Kontact crashes when i try to load a GPG-signed email in KMail module, while KMail itself works fine. Why? Unknown, but it’s due to visibility. aRTs still have the same problem: segmentation fault, same backtrace as before, more or less. So the GCC bug doesn’t seems to be the true responsible of all of that.
The problem with this visibility stuff is that, if the “conditions” found by configure are accomplished (so patched QT and whatever GCC4 is present), visibility is enabled. By default. No question asked. No way to disable it with ./configure switches…
I seem to be ranting? Well I am. Because this is going to be an headache for not only me and the rest of KDE herd in the future, but also for other maintainers that will start using GCC4 for KDE, maybe with a patched Qt, and will find out that arts crashes…. uh isn’t that what is happening in KUbuntu right now?
