On Mon, Feb 22, 2016 at 4:55 AM, Marek Polacek <polacek(a)redhat.com> wrote:
bogus errors with static data member template
fixed upstream and in gcc-6.0.0-0.11.fc24
I don't think this has been fixed. I updated ntl over the weekend,
and rebuilt Macaulay2 as part of that work. Macaulay2 still failed
with this same error, using gcc-6.0.0-0.11.fc24, so I added a patch to
workaround the issue, so as not to leave Macaulay2 with broken deps in
Rawhide. Indeed, the gcc-6.0.0-0.11.fc24 changelog says:
- temporarily revert PR c++/10200 fix
The fix must have caused other issues, I guess. I don't see anything
about that PR in the gcc-6.0.0-0.12.fc24 changelog, so I believe this
issue is still outstanding.
Now, this is a list of packages that very likely contain invalid
Some of them worked in the past, but only by luck and were just ill-fated.
Please try to fix the issues rather than adding workaround flags like
-fpermissive, -Wno-unused-but-set-variable etc.
Most of the issues should be described in porting_to, so I won't repeat it
here. Especially, if something fails, try using -fno-delete-null-pointer-checks
or -fno-lifetime-dse before opening a PR. However, it's certainly possible
that a compiler bug might crept it, and the code is valid. It's not feasible
for me to try to fix all these packages.
I already added -std=gnu++98 to this package, but the build still
fails. I don't understand the gcc error. GCC appears to be producing
non-const temporaries, and then complaining that the temporaries are
non-const. I asked for help with this about a week ago, and Jonathan
Wakely said he would take a look. I have not heard back from him yet:
Any ideas on what is going on there would be much appreciated.
The maddening thing is that upstream polymake has released a new
version, and the release notes say this new version brings "full C++11
compatibility". But I can't update to it, because it needs Singular
4.x and normaliz 3.x, and updating those 2 packages will break both
Macaulay2 and sagemath. Sigh.