Compilation failure with GCC 15 + cmake - bool is now a keyword (C23+)

[rbanffy]

When attempting to compile OpenSimH with GNU C++ 15.2.1 (Fedora 42) using the cmake script, I got the following failure:

In file included from /simh/slirp/slirp.h:4,
                 from /simh/slirp/arp_table.c:25:
/simh/slirp_glue/config-host.h:15:13: error: ‘bool’ cannot be defined via ‘typedef’
   15 | typedef int bool;
      |             ^~~~
/simh/slirp_glue/config-host.h:15:13: note: ‘bool’ is a keyword with ‘-std=c23’ onwards
/simh/slirp_glue/config-host.h:15:1: warning: useless type name in empty declaration
   15 | typedef int bool;
      | ^~~~~~~
gmake[2]: *** [slirp/CMakeFiles/slirp.dir/build.make:79: slirp/CMakeFiles/slirp.dir/arp_table.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2645: slirp/CMakeFiles/slirp.dir/all] Error 2
gmake: *** [Makefile:166: all] Error 2
*** cmake/cmake-builder.sh: Build errors detected. Exiting.

We can either dig into the source and fix it in a portable way, or ask the GNU compiler to check against a less strict standard.

[markpizz]

This problems only exists if you're compiling with g++.

Compiling with a C compiler (gcc or clang) has no such problem.
Nothing in open-simh requires using a C++ compiler.

[rbanffy]

I'm following the instructions in the `README-CMake.md` file and running `cmake/cmake-builder.sh`. I thought this was odd, as CMakeLists.txt sets -std to c99, but I don't know why a C++ compiler is being invoked.

…

On Fri, Oct 24, 2025 at 6:52 PM Mark Pizzolato ***@***.***> wrote: *markpizz* left a comment (open-simh/simh#490) <#490 (comment)> This problems only exists if you're compiling with g++. Compiling with a C compiler (gcc or clang) has no such problem. Nothing in open-simh requires using a C++ compiler. — Reply to this email directly, view it on GitHub <#490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNDCXZNT6NWTUXCKMQ3ET3ZJRNJAVCNFSM6AAAAACFKOT2QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBUGI2TQMBZGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Ricardo Bánffy http://about.me/rbanffy

[markpizz]

I'm not sure a C++ compiler is being invoked, however the makefile builds cleanly with gcc and clang AND BOTH g++ and clang++ without any changes.

The cmake building process introduces the problem you are encountering.

From my point of view, source code shouldn't have to make continuing changes to accommodate the tool chain used to build it.

[rbanffy]

I agree source shouldn't change to dodge toolchain changes - in this case, it seems the c99 is not being respected when calling the compiler. I'm very new to cmake and I'm not sure how to fix it.

[pkoning2]

It's true that source code should not have to change when compilers do, but unfortunately that doesn't always work. The trouble is when compilers change the default rev of the language standard they use. Or, on a smaller scale, when they improve error checking and detect what was always wrong but not previously checked for. In both cases, we have to either adjust the code, or the build command lines.

For the case of the language standard, telling the compiler to use the older standard may be a good answer. I know GCC can do that, and presumably also clang since it emulated gcc in many ways. I have no idea if the MS compiler has the ability.

On error checking, usually the right answer is to fix the error. Sometimes that's painful enough that setting a compiler flag that avoids doing the thing that was caught is the better option, but I dislike that in general. The fact that Linux depends on a half dozen compiler flags to disable normal C standard rules seems very ugly, and I'd rather not have SIMH do such things. Examples include the undefinedness of signed int overflow, the pointer aliasing rules, and others like that.

[markpizz]

If this problem arose in a vacuum, then changing the code might be appropriate, BUT the compilers (gcc and./or clang) DID NOT change and they operate correctly with this code when building with the makefile.

[rbanffy]

If I got everything right from your comments, if the build using make works, then the issue is in the cmake build process that appears not to be passing the --cstd=c99 switch to the compiler as make does. If the issue were just the redefinition of bool, then wrapping it in a conditional would make sense, but the fact the build with make works proves it's not.

I am digging into the cmake-builder.sh script, but I'm no expert in it. I'm trying to figure out where the --std ball is being dropped, but there is a lot of behavior I don't understand (yet).

Is there any general advice on what the "official" way to build is? Initially I thought that cmake was the way to do it, but, it seems, it is not a popular one, or the issue I observed would have popped up sooner.

[pkoning2]

Re official way: cmake is a recent addition and the intent is for it to be just as good and (hopefully) more maintainable and flexible. We're probably not quite there yet. If there are mismatches in compiler flags between the two, it would be good to fix that (with the flags from the makefile considered authoritative, unless there is reason to argue why that isn't the right assumption.)

[rbanffy]

Thank you - this makes it clear. Anyway, the problem is in the cmake build process. I'll try to figure it out, but, if someone with more experience with it wants to come forward, I'll be pleased.

[2kbits]

I ran into the same problem when trying to compile the project on arch linux. I figured out that you can set CMAKE_C_STANDARD in CMakeLists.txt to override the c23 default. It sounds like the project uses c99 so thats what I set it to. I submitted a pull request. Let me know if this is the solution you were looking for or if I need to change something.