[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