Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL

[Michael Pyne]

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 [1] 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 
now. :)

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 [1] (both of whom I trust more than 
myself on this topic).

Researching further, the GCC libstdc++ page [2] 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 
file.

The detailed GCC ABI spec is at [3] 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.

[1] http://permalink.gmane.org/gmane.comp.lib.qt.devel/3681
[2] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-
Options.html#Code%20Gen%20Options
[3] http://sourcery.mentor.com/public/cxx-abi/abi-eh.html#cxx-abi

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120614/78d977d5/attachment.sig>