[kde-freebsd] devel/smokekde

Schaich Alonso alonsoschaich at fastmail.fm
Wed Aug 14 10:15:17 UTC 2013


On Tue, 13 Aug 2013 15:13:40 +0200
Dimitry Andric <dim at FreeBSD.org> wrote:

> 
> On Aug 13, 2013, at 07:48, Schaich Alonso <alonsoschaich at 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


More information about the kde-freebsd mailing list