I'm experimentally rebuilding rawhide with the not-yet-released GCC 15 to see if anything breaks, and to help write the porting guide. See https://fedoraproject.org/wiki/User:Dmalcolm/gcc-15 My test build with GCC 15 failed: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed/build/8476052/ whereas my test build with GCC 14 succeeded: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/build/8477625/ Looking at the failure logs e.g. https://download.copr.fedorainfracloud.org/results/dmalcolm/gcc-15-smoketest-3.failed/fedora-rawhide-x86_64/08476052-Singular/builder-live.log.gz I see: extra.cc: In function 'BOOLEAN jjEXTENDED_SYSTEM(leftv, leftv)': extra.cc:3850:11: error: 'convSingPFlintP' was not declared in this scope 3850 | convSingPFlintP(fre,(poly)h->Data(),currRing); h=h->next; | ^~~~~~~~~~~~~~~ extra.cc:3857:11: error: 'convSingNFlintN' was not declared in this scope 3857 | convSingNFlintN(center_re,(number)h->Data(),currRing->cf); h=h->next; | ^~~~~~~~~~~~~~~ extra.cc:3892:27: error: 'convFlintNSingN' was not declared in this scope 3892 | ll->m[0].data=convFlintNSingN(re_part[i],currRing->cf); | ^~~~~~~~~~~~~~~ I've written some notes on C++ name lookup failures here: https://fedoraproject.org/wiki/User:Dmalcolm/gcc-15#C++:_error_with_-Wtemplate-body but the above error doesn't seem to be in a template, so this might well be a different problem. Reproducible: Always
There's an upstream issue about GCC 15 compatibility although it seems to be a different error: https://github.com/Singular/Singular/issues/1242
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Patch available upstream: https://github.com/Singular/Singular/commit/338804e105a7f26354ea1aed723ba65f9ccb3320
Looks like this got built successfully during the mass rebuild without the upstream fix: https://koji.fedoraproject.org/koji/buildinfo?buildID=2616859 Maybe this was an unrelated issue, or maybe even a gcc bug that got fixed between the prebuild and rebuild?
It was actually a problem in a flint header. A noreturn attribute was specified in a non-C23-compliant way. I pushed a fix for that on Tuesday so that flint-using packages wouldn't all fail the mass rebuild. I'm glad that worked for Singular, at least.
Awesome, I'll close this off then, thanks!