I must confess I have a bit of a soft spot for classic DOOM. Despite 31 long years, the game is still mighty fun to play yourself (admittedly, I rather suck at it) or to watch others play it (this one I'm better at); and with the source code being available, you can enjoy it on every modern platform – be it desktop, smartphone, digital camera, oscilloscope, or anything else you can imagine. As a result of this, through various circumstances, I came to maintain several DOOM-related packages in Fedora Linux.
Now, a few months before each new release, the Fedora Linux project performs a mass rebuild of all its packages. This has a few benefits, such as ensuring ABI compatibility, updating statically-linked dependencies, making use of new compiler optimisations/code hardening options, and so on. Either way, with Fedora Linux 42 slated to be released mid-April, the time for the Mass Rebuild has come – and, as it often happens, not all of my packages made it through. One of those that failed the rebuild was chocolate-doom .
Two times false does not make right
Well, all right. The first step to finding out what happened was to check the build logs.
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src -I/usr/include/SDL2 -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL2 -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL2 -D_GNU_SOURCE=1 -D_REENTRANT -O2 -g -Wall -Wdeclaration-after-statement -Wredundant-decls -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/include/SDL2 -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libpng16 -DWITH_GZFILEOP -I/usr/include/pipewire-0.3 -I/usr/include/spa-0.2 -D_REENTRANT -I/usr/lib64/pkgconfig/../../include/dbus-1.0 -I/usr/lib64/pkgconfig/../../lib64/dbus-1.0/include -I/usr/include/libinstpatch-2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -I/usr/include/opus -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -c -o deh_bexstr.o deh_bexstr.c In file included from ../../src/sha1.h:21, from ../../src/deh_defs.h:21, from deh_bexstr.c:22: ../../src/doomtype.h:113:5: error: cannot use keyword ‘false’ as enumeration constant 113 | false, | ^~~~~ ../../src/doomtype.h:113:5: note: ‘false’ is a keyword with ‘-std=c23’ onwards
Oh, so this was a compilation error. Having received a lot of flak over the years about cryptic error messages, GCC spent the last few years vastly improving on this front; and now, the error message I got, together with the note that followed it, made the issue clear. Inside the engine code, chocolate-doom declares its own boolean type:
#if defined(__cplusplus) || defined(__bool_true_false_are_defined) typedef bool boolean ; #else typedef enum { false , true } boolean ; #endif
So, when treating the sources as C++, it uses the C++ bool type, whereas when treating the sources as C, it ships its own, custom type. This worked fine with older C standards, as C89 did not contain a boolean type at all, whereas the type introduced by C99 was named _Bool – though you could include the
Ok, so it makes perfect sense that this custom boolean type clashes with the false and true keywords – but begs the question, why did it fail now, when it worked perfectly fine a few months ago? Why does it build as C23?
A fairly standard change
... continue reading