Project

General

Profile

Actions

Bug #21286

closed

Windows - MSYS2 just updated to GCC 15.1.0, builds failing

Added by MSP-Greg (Greg L) 8 days ago. Updated 3 days ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:121745]

Description

MSYS2 just updated to GCC 15.1.0, and the ruby-loco builds failed to compile.

See MinGW & UCRT

Also, I compiled mswin locally with the recent VS 'preview' release, and the bug has been fixed.


Related issues 1 (1 open0 closed)

Related to Ruby - Bug #21293: C23/GCC 15 build breakage with rb_define_method() and friendsOpenActions

Updated by byroot (Jean Boussier) 8 days ago

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)}

Updated by Earlopain (Earlopain _) 7 days ago

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)

Updated by mdalessio (Mike Dalessio) 7 days ago

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.

Updated by MSP-Greg (Greg L) 7 days ago

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...

Updated by MSP-Greg (Greg L) 7 days ago

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.

Actions #6

Updated by alanwu (Alan Wu) 6 days ago

  • Related to Bug #21293: C23/GCC 15 build breakage with rb_define_method() and friends added

Updated by alanwu (Alan Wu) 6 days ago · Edited

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

Updated by MSP-Greg (Greg L) 6 days ago

@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.

Updated by hsbt (Hiroshi SHIBATA) 6 days ago

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.

Actions #10

Updated by alanwu (Alan Wu) 6 days ago

  • Status changed from Open to Closed

Applied in changeset git|719486a642f0e282b02b958069b8b39b85b3aa1e.


Fix C23 (GCC 15) WIN32 compatibility for rb_define_* functions

Fixes [Bug #21286]

Updated by johnnyshields (Johnny Shields) 3 days ago · Edited

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).

Actions #12

Updated by nagachika (Tomoyuki Chikanaga) 3 days ago

  • Backport changed from 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN to 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0