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/8476055/ whereas my test build with GCC 14 succeeded: https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/build/8477614/ Looking at the failure logs e.g. https://download.copr.fedorainfracloud.org/results/dmalcolm/gcc-15-smoketest-3.failed/fedora-rawhide-x86_64/08476055-a2ps/builder-live.log.gz I see: parseppd.y:157:1: error: conflicting types for 'yyprint'; have 'void(FILE *, int, YYSTYPE)' 157 | yyprint (FILE *file, int type, YYSTYPE value) | ^~~~~~~ parseppd.y:53:13: note: previous declaration of 'yyprint' with type 'void(void)' 53 | static void yyprint (); | ^~~~~~~ This is probably due to GCC 15 now defaulting to -std=gnu23, whereas GCC 14 defaulted to -std=gnu17, and C23 is stricter about function prototypes than C17. It's probably fixable by fixing the function prototype (or by manually adding -std=gnu17 to the C build flags) Reproducible: Always
Hi Dave, I've tried to reproduce the build failure with your steps from https://fedoraproject.org/wiki/User:Dmalcolm/gcc-15#Trying_it_yourself , but the mockbuild fails when installing the buildroot, because it includes old libtool which was built with old gcc, which conflicts with the new one. Can you update your copr project to include rebuilt libtool?
Possible fix https://src.fedoraproject.org/fork/zdohnal/rpms/a2ps/c/81c3a1ca994ab93ef92bde4a218920405f5ecf06?branch=bz2336012
The mass rebuild will start today with the new gcc15, so hopefully it'll be easier to reproduce and fix.
FEDORA-2025-7b4cc24b44 (a2ps-4.15.6-3.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7b4cc24b44
FEDORA-2025-7b4cc24b44 (a2ps-4.15.6-3.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.