Compile error on Fedora 42

[lukef]

Fedora 42 uses the updated GCC 15 toolchain and I think (??) that is causing problems compiling.

A lot of errors like:

note: ‘bool’ is defined in header
‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’

error: unknown type name ‘bool’
  334 | static bool
      |        ^~~~

I'm using:

mise 2025.4.5 linux-x64 (2025-04-18)
ruby 3.4.3

Sorry, let me know what other information is useful here.

[tarcieri]

I'm a bit confused where the linked code is supposed to be. The token bool doesn't appear in any of the C code in this library

[lukef]

Ugh, sorry. The linked code is all in the ruby 3.4 source.

<mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/core/rtypeddata.h:578:15: note: ‘bool’ is defined in
header ‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’
In file included from <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/ruby.h:42:
<mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:420:5: error: unknown type name ‘bool’
  420 |     bool left;                  /**< Whether overflow happened or not. */
      |     ^~~~
<mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:65:1: note: ‘bool’ is defined in header
‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’
   64 | #include "ruby/internal/stdckdint.h"
  +++ |+#include <stdbool.h>
   65 | #include "ruby/internal/xmalloc.h"
<mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h: In function ‘rbimpl_size_mul_overflow’:
<mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:574:49: error: ‘false’ undeclared (first use in
this function)
  574 |     struct rbimpl_size_mul_overflow_tag ret = { false,  0, };
      |                                                 ^~~~~

[tarcieri]

Seems like this may be an upstream Ruby issue then?

[lukef]

Ruby itself compiles fine. This error occurs when I run gem install ed25519 or when it's a dependency of another Gem (like Kamal). I can report it on the Kamal issues as this is where it is failing. It prevents any new Rails install from being able to be used.

[tarcieri]

Well, that is to say, this doesn't appear to be an ed25519 issue

[dennmart]

I just did a fresh install of Fedora 42 on my PC, and I'm running into this same issue using the latest version of asdf. It fails to build the gem's native extensions on any recent Ruby version I tested out (3.2.x, 3.3.x and 3.4.x). Here's the full error log I have in my system, in case it's helpful: https://gist.github.com/dennmart/f48387722779931eb5fe2860179d064b

Fedora 42 updated the GNU toolchain to GCC 15 and other tooling, so I'm suspecting this has to do with the error.

I haven't run into any other gem build issues so far, just this gem.

[tjbarber]

I am also running into this issue with a similar error log.

[tarcieri]

I don't see any errors there that are originating in the source code of ed25519 itself (just one warning).

I have no idea what the problem would be. All of the errors are originating in Ruby's header files.

I would still suggest someone try to open an upstream issue on ruby-core and see if they have any advice.

[haniqassim]

Same problem here on Fedora 42

[tarcieri]

We don’t need additional reports of the problem, the existing ones are confirmation enough.

Has anyone opened a ruby-core issue yet?

[tjbarber]

I have not, it looks like there might be one here based off of this comment

[lukef]

Issue created here in case anyone wants to add further information.

https://bugs.ruby-lang.org/issues/21290

[dennmart]

Not sure if this is helpful, but I pulled down the source code to tinker around and found these CFLAGS for the file that doesn't compile on Fedora 42:

ed25519/ext/ed25519_ref10/extconf.rb

Line 6 in 4ab4663

$CFLAGS << " -Wall -O3 -pedantic -std=c99"

Removing the -std=c99 flag makes the gem extensions build correctly, so the issues seem to be stemming from this particular flag. I haven't done any C programming for at least two decades, so I have no clue about what's happening, or whether this flag is necessary on other systems.

[tarcieri]

Looking at the SUPERCOP test suite from which the C code was originally extracted, I see -std=c99 documented as follows:

Note: to enable 64-bit types on 32-bit compilers, it might be
necessary to switch from ISO C90 mode to ISO C99 mode (e.g., gcc
-std=c99), or to allow compiler-specific extensions.

However, I don't see this being applied to the specific module from which this code was extracted, nor does that comment appear anywhere in the extracted code.

Perhaps we can try shutting it off and see if that addresses the issue.

[dennmart]

I opened a pull request that should fix this issue (#45).