Bug 2336033

Summary:	airspyone_host fails to build with GCC15 / C23 ("typedef int bool;")
Product:	[Fedora] Fedora	Reporter:	Dave Malcolm <dmalcolm>
Component:	airspyone_host	Assignee:	Jaroslav Škarvada <jskarvad>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	josmyers, jskarvad
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	airspyone_host-1.0.10-9.fc42 airspyone_host-1.0.10-10.fc42	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-01-07 12:19:56 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:56:02 UTC

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:

whereas my test build with GCC 14 succeeded:

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

/builddir/build/BUILD/airspyone_host-1.0.10-build/airspyone_host-1.0.10/libairspy/src/airspy.c:38:13: error: two or more data types in declaration specifiers
   38 | typedef int bool;
      |             ^~~~
/builddir/build/BUILD/airspyone_host-1.0.10-build/airspyone_host-1.0.10/libairspy/src/airspy.c:38:1: warning: useless type name in empty declaration
   38 | typedef int bool;
      | ^~~~~~~

This is probably due to GCC 15 now defaulting to -std=gnu23, whereas GCC 14 defaulted to -std=gnu17, and "bool" is a reserved word in C23.  The code should be ported to support C23 (but it could probably be worked around by manually adding -std=gnu17 to the C build flags)


Reproducible: Always

Comment 1 Jaroslav Škarvada 2025-01-07 11:44:20 UTC

Thanks for the info. I am going to propose the following fix upstream:

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 202311L)
  #define _STD_C23
#endif

#ifndef _STD_C23
typedef int bool;
#endif

If there is a better way how to handle it, please let me know.

Comment 2 Fedora Update System 2025-01-07 12:16:30 UTC

FEDORA-2025-a97ed07ba8 (airspyone_host-1.0.10-9.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-a97ed07ba8

Comment 3 Fedora Update System 2025-01-07 12:19:56 UTC

FEDORA-2025-a97ed07ba8 (airspyone_host-1.0.10-9.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 4 Dave Malcolm 2025-01-07 15:09:57 UTC

Jaroslav: thanks!

Joseph: with your "C23 expert" hat on, does this fix seem like the correct one?

Comment 5 Joseph Myers 2025-01-07 17:30:01 UTC

Yes, that seems right, assuming (a) the bool definition is genuinely used as a boolean type (only values 0 and 1 stored) and (b) it's not part of an externally supported library ABI (if bool appears in a library ABI, you might need to be more careful about considering whether such a change is an incompatible ABI change).

Comment 6 Jaroslav Škarvada 2025-01-07 20:30:37 UTC

Thanks, Is the new bool stored differently from the integer? I.e. will the consumers of the ABI crash if not recompiled?

Comment 7 Fedora Update System 2025-01-09 10:48:47 UTC

FEDORA-2025-72f8c85e7b (airspyone_host-1.0.10-10.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-72f8c85e7b

Comment 8 Fedora Update System 2025-01-09 10:52:56 UTC

FEDORA-2025-72f8c85e7b (airspyone_host-1.0.10-10.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 Jaroslav Škarvada 2025-01-09 11:03:10 UTC

Nevermind, although I think it won't probably crash and additionally the library and its consumers are usually (re)compiled with the same compiler/standard it isn't problem any more, because upstream prefers solution with enforced older C standard, so I updated the patch.