Ruby

I'm seeing the same thing on ruby/json GitHub Actions builds.

bigdecimal.c:2556:1: note: 'BigDecimal_truncate' declared here 2556 | BigDecimal_truncate(int argc, VALUE *argv, VALUE self) | ^~~~~~~~~~~~~~~~~~~ bigdecimal.c:4636:47: error: passing argument 3 of 'rb_define_method' from incompatible pointer type [-Wincompatible-pointer-types] 4636 | rb_define_method(rb_cBigDecimal, "_dump", BigDecimal_dump, -1); | ^~~~~~~~~~~~~~~ | | | VALUE (*)(int, VALUE *, VALUE) {aka long long unsigned int (*)(int, long long unsigned int *, long long unsigned int)} 

I'm getting the same thing in windows CI runs for a bunch of other first-party gems:

• date
• fiddle
• io-console
• stringio
• racc
• prism

The errors all look similar, for example here it is for prism:

api_pack.c: In function 'Init_prism_pack': api_pack.c:269:56: error: passing argument 3 of 'rb_define_singleton_method' from incompatible pointer type [-Wincompatible-pointer-types] 269 | rb_define_singleton_method(rb_cPrismPack, "parse", pack_parse, 3); | ^~~~~~~~~~ | | | VALUE (*)(VALUE, VALUE, VALUE, VALUE) {aka long long unsigned int (*)(long long unsigned int, long long unsigned int, long long unsigned int, long long unsigned int)} In file included from C:/hostedtoolcache/windows/Ruby/3.4.3/x64/include/ruby-3.4.0/ruby/internal/anyargs.h:76, from C:/hostedtoolcache/windows/Ruby/3.4.3/x64/include/ruby-3.4.0/ruby/ruby.h:27, from C:/hostedtoolcache/windows/Ruby/3.4.3/x64/include/ruby-3.4.0/ruby.h:38, from D:/a/rubocop/rubocop/vendor/bundle/ruby/3.4.0/gems/prism-1.4.0/ext/prism/extension.h:6, from api_pack.c:1: C:/hostedtoolcache/windows/Ruby/3.4.3/x64/include/ruby-3.4.0/ruby/internal/intern/class.h:365:68: note: expected 'VALUE (*)(void)' {aka 'long long unsigned int (*)(void)'} but argument is of type 'VALUE (*)(VALUE, VALUE, VALUE, VALUE)' {aka 'long long unsigned int (*)(long long unsigned int, long long unsigned int, long long unsigned int, long long unsigned int)'} 365 | void rb_define_singleton_method(VALUE obj, const char *mid, VALUE(*func)(ANYARGS), int arity); | ~~~~~~~^~~~~~~~~~~~~~ api_pack.c:181:1: note: 'pack_parse' declared here 181 | pack_parse(VALUE self, VALUE version_symbol, VALUE variant_symbol, VALUE format_string) { | ^~~~~~~~~~ make: *** [Makefile:251: api_pack.o] Error 1 

Those are actually almost all gems in my lockfile that have native extensions, so this looks like a very widespread issue (in CI at least)

I wonder if -Werror is being set implicitly?

I'm seeing similar failures up and down my CI pipelines for the gems mentioned by @Earlopain, in addition to libxml2 compilation in Nokogiri's upstream integration testing.

Maybe gcc-15 could be added to https://github.com/ruby/ruby/blob/master/.github/workflows/compilers.yml?

We don't know if this is a Windows only issue or if this is an issue with all OS's using gcc.

Also, see info in Porting to GCC 15?

We could force setup-ruby to install gcc-14, and bypass the upgrade to gcc-15? It would take a little work...

I just updated the code in https://github.com/ruby/setup-msys2-gcc (the repo that assembles Windows build tool archive files), it is now downgrading to gcc 14.

I think this should fix the issue. I checked with Puma (extension gem), as it was affected.

At some point, I assume we'll be able to re-enable gcc-15 for a limited set of Ruby versions.

Lastly, I added -std=gnu17 to CFLAGS (as per the above 'Porting to GCC 15'), and Ruby master built locally.

I sent https://github.com/ruby/ruby/pull/13202 which I believe should fix compatibility with GCC 15 on MinGW (it passed CI with -std=c23 on GCC 14). Is there a way to explicitly pick GCC 15 on CI with setup-ruby?

We don't know if this is a Windows only issue or if this is an issue with all OS's using gcc.

It's a bit of both, but Windows gets more exposure in this case because we special cased it to mitigate against an older bug (#16134). See #21293

@alanwu (Alan Wu)

Thanks for working on this.

it passed CI with -std=c23 on GCC 14

I'm not that familiar with gcc, especially in terms of issues like this. Are you pretty certain that -std=c23 on GCC 14 is the same as GCC 15? I can check that locally...

Is there a way to explicitly pick GCC 15 on CI with setup-ruby?

At present, no. One could use setup-ruby-pkgs, let me try that with your PR.

Going forward, I see a need to be able to use GCC 14 with older Rubies, and GCC 15 with newer ones. The selection should be automatic, but along with it, an override would be helpful, especially for building Ruby.

An override example would be a base Ruby that was UCRT (loaded with setup-ruby), but the script was building an MSWIN Ruby. Having the override would elimination a chicken/egg problem that often exists.

Some background:

The code that creates 7z packages of build tools (stored in a release) is contained in ruby/setup-msys2-gcc. The code in setup-ruby downloads and extracts the correct 7z files based on the Ruby version (no functioning override yet).

At present, there are two 'vectors' of build tool selections, [ucrt, mingw] and [OpenSSL 1.1, OpenSSL 3.y], which creates four different build tool packages. Now, I need another for GCC version [14, 15]. We're also adding arm64 packages.

I'll move forward with creating packages accounting for GCC 14 and GCC 15.

I added gcc-15 to our CI: https://github.com/ruby/ruby/actions/runs/14746546198/job/41394898928#step:7:670

It's working fine with Ubuntu-25.04. This issue only happened with MSYS2 or Windows environment.

Please kindly backport this to all actively maintained versions (3.2, 3.3, 3.4). Since MSYS2 gcc is installed independent of Ruby, users installing any Ruby version using the Ruby Installer for Windows will face the same problem (inability to compile native gems).

Will you create new ruby stable releases in the next days? I'm asking because I've seen many CI failures and bug reports due to this GCC-15 issue and I wonder if I should release a new RubyInstaller series with this patch or if there will be official new ruby patch releases. There's also the net-imap CVE pending a new release.

I will :) I'm planning to cut an early Ruby 3.4 release this week.