Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
mpyne at kde.org
Thu Jun 14 22:25:48 UTC 2012
On Thursday, June 14, 2012 20:18:04 Albert Astals Cid wrote:
> El Dijous, 14 de juny de 2012, a les 15:36:47, David Faure va escriure:
> > On Tuesday 12 June 2012 20:42:28 Michael Pyne wrote:
> > > Hi all,
> > >
> > > Bug 301419 has been reported against kdelibs due to a build failure when
> > > KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform
> > > even more sanity checking in the KSharedDataCache.
> > >
> > > These commits use exceptions (as are already used in khtml) since they
> > > are
> > > actually "the right tool" in the context of where they are used, and
> > > because refactoring everything to use error codes everywhere (ECE) would
> > > have risked introducing more bugs.
> > >
> > > In order to minimize the changes to kdecore I only added the CMake magic
> > > to
> > > enable exceptions for only kshareddatacache.cpp. This doesn't work when
> > > KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that
> > > case.
> > >
> > > The Mageia devs have a proposed patch  to enable exceptions for all
> > > of
> > > kdecore, which fixes the issue. Is it acceptable for me to go this
> > > route?
> > > The only real alternative this late in the game is to back out the
> > > sanity
> > > checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL
> > > will
> > > not work for this tarball although it worked for 4.8.3, both of which I
> > > consider less desirable. But I don't want to make the change if there
> > > are
> > > good reasons to avoid it.
> > The alternative would be to enable exceptions for all of kdecore only if
> > enable-final is enabled.
> Is that binary compatible?
If I'm understanding it right, it would add extra typeinfo classes for kdecore
but would remain binary-compatible with older code. It is not mentioned at all
in our TechBase binary compatibility page, which is even the #1 Google hit
Also the flag itself is claimed as binary compatible (in the context of code
that doesn't actually /use/ exceptions) in some discussion on the Qt dev list,
by Olivier Goffart and Thiago Macieira  (both of whom I trust more than
myself on this topic).
Researching further, the GCC libstdc++ page  mentions that exception
handling is part of the ABI, but I can only assume this is in the context of
"does this code throw exceptions or not" as opposed to whether non-exception-
using code would care about that flag. The GCC docs on -fexceptions talk about
extra code to propagate exceptions and perhaps data size overhead but there's
no specific warning regarding changing the ABI visible outside of the object
The detailed GCC ABI spec is at  and it seems to me from my reading of it
that the changes involved are changes to data included with the .o, changes in
function implementations, and extra calls to the C++ runtime library... but no
changes to symbol names, mangling, etc. As far as I can tell this change
should be binary compatible.
As an experiment I've recompiled kdecore here with exceptions and run KDevelop
(which I think is a fair exercise of much of the breadth of kdecore
technologies) and wasn't able to find any new issues from that change.
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the release-team