Bug 2336028

Summary: abe fails to build with gcc 15 ("Map.c:948:9: error: too many arguments to function 'finishDrawMap'")
Product: [Fedora] Fedora Reporter: Dave Malcolm <dmalcolm>
Component: abeAssignee: Gwyn Ciesla <gwync>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: gwync, wart
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-01-08 21:54:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2333037    

Description Dave Malcolm 2025-01-06 22:38:19 UTC 
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora

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/8476060/

whereas my test build with GCC 14 succeeded:
https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-15-smoketest-3.failed.checker/build/8477619/

Looking at the failure logs e.g.
https://download.copr.fedorainfracloud.org/results/dmalcolm/gcc-15-smoketest-3.failed/fedora-rawhide-x86_64/08476060-abe/builder-live.log.gz
I see:

Map.c: In function ‘moveMap’:
Map.c:948:9: error: too many arguments to function ‘finishDrawMap’
  948 |         finishDrawMap(!map.redraw);
      |         ^~~~~~~~~~~~~
Map.c:15:6: note: declared here
   15 | void finishDrawMap();
      |      ^~~~~~~~~~~~~

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 prototypes (or by manually adding -std=gnu17 to the C build flags)


Reproducible: Always
Comment 1 Gwyn Ciesla 2025-01-08 21:54:52 UTC 
Thank you! Since the parameter was ignored, I just dropped it, so it should be fine now.