Bug 2336033 - airspyone_host fails to build with GCC15 / C23 ("typedef int bool;")
Summary: airspyone_host fails to build with GCC15 / C23 ("typedef int bool;")
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: airspyone_host
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: gcc-15-mass-prebuild
TreeView+ depends on / blocked
 
Reported: 2025-01-06 22:56 UTC by Dave Malcolm
Modified: 2025-01-09 11:03 UTC (History)
2 users (show)

Fixed In Version: airspyone_host-1.0.10-9.fc42 airspyone_host-1.0.10-10.fc42
Clone Of:
Environment:
Last Closed: 2025-01-07 12:19:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.