Created attachment 1125254 [details]
build.log

Created attachment 1125255 [details]
root.log

Created attachment 1125256 [details]
state.log

MathStructure.cc:7166:53: error: no matching function for call to 'MathStructure::gcd(MathStructure&, MathStructure&, MathStructure&, const EvaluationOptions&, bool)'
  MathStructure::gcd(cont_c, cont_d, gamma, eo, false);
                                                     ^

This looks like the "Cannot convert 'bool' to 'T*'" case in the Porting to GCC 6 page.  Change the false to NULL.

I either messed up the patch or there is another issue ... :(

Looking ...

https://koji.fedoraproject.org/koji/taskinfo?taskID=13016298

This now fails due to a missing BuildRequires:
Can't locate Getopt/Long.pm in @INC (you may need to install the Getopt::Long module) (@INC contains: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at ../intltool-merge line 42.

By the way, using NULL in C++ is not that great an idea. It will work in most cases (and should be fine here), but e.g. for varargs functions, on some platforms, you may be in for a surprise. (Though, as far as I know, glibc with g++ defines it to __null, which behaves essentially the same as the C++11 nullptr and is thus safe. Concretely, the issue is that some platforms just define NULL to 0, which then has the wrong size when passed to a varargs function.) For code that requires C++11, nullptr can be used, otherwise, static_cast<Foo *>(0) (with the correct Foo type) is the most portable and safe version.

(In reply to Kevin Kofler from comment #6)
> This now fails due to a missing BuildRequires:
> Can't locate Getopt/Long.pm in @INC (you may need to install the
> Getopt::Long module) (@INC contains: /usr/local/lib/perl5
> /usr/local/share/perl5 /usr/lib/perl5/vendor_perl
> /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at
> ../intltool-merge line 42.

IOW, add BuildRequires: perl(Getopt::Long)

> By the way, using NULL in C++ is not that great an idea. It will work in
> most cases (and should be fine here), but e.g. for varargs functions, on
> some platforms, you may be in for a surprise. (Though, as far as I know,
> glibc with g++ defines it to __null, which behaves essentially the same as
> the C++11 nullptr and is thus safe. Concretely, the issue is that some
> platforms just define NULL to 0, which then has the wrong size when passed
> to a varargs function.)

In theory, yes, but NULL should be safe with either GCC or Clang regardless of target.  <stddef.h> is provided by GCC, and while the headers may be used by clang they both define __GNUG__ in C++:

#ifdef __GNUG__
#define NULL __null
#else   /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else   /* C++ */
#define NULL 0
#endif  /* C++ */
#endif  /* G++ */

(In reply to Kevin Kofler from comment #6)
> This now fails due to a missing BuildRequires:
> Can't locate Getopt/Long.pm in @INC (you may need to install the
> Getopt::Long module) (@INC contains: /usr/local/lib/perl5
> /usr/local/share/perl5 /usr/lib/perl5/vendor_perl
> /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at
> ../intltool-merge line 42.


Yup! I just had noticed it going through the build log ... 

Thanks a lot Kevin!

nonamedotc's libqalculate-0.9.7-17.fc24 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=736865

Thanks again Yaakov and Kevin.