On Tue, 13 Aug 2013 15:13:40 +0200 Dimitry Andric <d...@freebsd.org> wrote:
> > On Aug 13, 2013, at 07:48, Schaich Alonso <alonsoscha...@fastmail.fm> wrote: > > devel/smokekde seems to use the -fno-exceptions compiler switch to disable > > C++ exceptions, while at the same time it refers to some inline code of > > akonadi that uses exceptions > > (${KDEPREFIX}/include/akonadi/itempayloadinternals_p.h:164 for example), > > which therefore fails to build. The way I see it we can either remove the > > -fno-exception flag and eventually have an exception be thrown into non-C+ > > + code (undefined behaviour), or remove akonadi wrapper generation from > > smokekde, which eventually will become troublesome if some smokekde > > consumer (other ports or other parts of smokekde as well) attempts to use > > it. > > This is most likely the same problem I discussed with rakuco on IRC, > e.g. clang generates errors when parsing the template, instead of when > instantiating it, as gcc does. > > Take for example: > > template<typename T> void foo() { throw 42; } > > then g++ -fno-exceptions will not complain, but if you add: > > void bar() { foo<int>(); } > > g++ -fno-exceptions will give a similar error ("exception handling > disabled, use -fexceptions to enable"). > > A workaround for clang is to use the -fdelayed-template-parsing option, > which will postpone (most of) the parsing until instantiation time. > > Of course the best option is for the upstream software to fix their > inline code to only use exceptions when they are enabled, for example by > testing __has_feature(cxx_exceptions), or the __EXCEPTIONS define. > > -Dimitry > Thanks for the reply. I think using -fdelayed-template-parsing is the way to go here, as the __has_feature one would need to modify a large number of files. Alonso _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information