Build fails on GCC 12

[TheMarex]

Issue Description

When trying to run bazelisk build //... on Arch Linux with GCC version 12.2.0 the build of @org_ruby_lang_ruby_toolchain fails because the compiler does not understand some legacy flags. Of course this is not an issue for downstream if you do not depend on ruby, however I was trying to work on rules_proto_grpc and this prohibits me from running //tools/rulegen without patching the ruby support out of the repo first. I suspect more contributors will run into similar issues soon, which doesn't exactly improve the development experience.

I looked into bumping the version forrules_ruby since I suppose this is and issue that was fixed for ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) which is my systems local version and was compiled with GCC 12 successfully. However rules_ruby seems not maintained given this PR is still open. @pcj given you added support for this initially: Should ruby support be removed or disabled by default?

Log Output

Last 10 log lines:
cc1: note: unrecognized command-line option ‘-Wno-parentheses-equality’ may have been intended to silence earlier diagnostics
cc1: note: unrecognized command-line option ‘-Wno-constant-logical-operand’ may have been intended to silence earlier diagnostics
linking shared-object socket.so
make[2]: Leaving directory '/tmp/ruby-build.20221214124610.22866.dbrN3G/ruby-3.0.2/ext/socket'
linking shared-object zlib.so
make[2]: Leaving directory '/tmp/ruby-build.20221214124610.22866.dbrN3G/ruby-3.0.2/ext/zlib'
linking shared-object ripper.so
make[2]: Leaving directory '/tmp/ruby-build.20221214124610.22866.dbrN3G/ruby-3.0.2/ext/ripper'
make[1]: Leaving directory '/tmp/ruby-build.20221214124610.22866.dbrN3G/ruby-3.0.2'
make: *** [uncommon.mk:300: build-ext] Error 2
INFO: Repository org_ruby_lang_ruby_toolchain instantiated at:
  /home/patrick/Code/rules_proto_grpc/WORKSPACE:267:22: in <toplevel>
  /home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/bazelruby_rules_ruby/ruby/private/sdk.bzl:29:22: in rules_ruby_select_sdk
Repository rule ruby_runtime defined at:
  /home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/bazelruby_rules_ruby/ruby/private/toolchains/ruby_runtime.bzl:150:31: in <toplevel>
INFO: Repository 'org_ruby_lang_ruby_toolchain' used the following cache hits instead of downloading the corresponding file.
 * Hash 'afd8aa2d05fb2f33c09c78dabcd2fc0bfa7e70dfc6b5288a1b5794337497039b' for https://github.com/rbenv/ruby-build/archive/refs/tags/v20210707.tar.gz
If the definition of 'org_ruby_lang_ruby_toolchain' was updated, verify that the hashes were also updated.
ERROR: An error occurred during the fetch of repository 'org_ruby_lang_ruby_toolchain':
   Traceback (most recent call last):
	File "/home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/bazelruby_rules_ruby/ruby/private/toolchains/ruby_runtime.bzl", line 133, column 35, in _ruby_runtime_impl
		ruby = ruby_repository_context(ctx, interpreter_path)
	File "/home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/bazelruby_rules_ruby/ruby/private/toolchains/repository_context.bzl", line 42, column 40, in ruby_repository_context
		interpreter_path = interpreter_path.realpath
Error: /home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/org_ruby_lang_ruby_toolchain/build/bin (No such file or directory)
ERROR: /home/patrick/Code/rules_proto_grpc/WORKSPACE:267:22: fetching ruby_runtime rule //external:org_ruby_lang_ruby_toolchain: Traceback (most recent call last):
	File "/home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/bazelruby_rules_ruby/ruby/private/toolchains/ruby_runtime.bzl", line 133, column 35, in _ruby_runtime_impl
		ruby = ruby_repository_context(ctx, interpreter_path)
	File "/home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/bazelruby_rules_ruby/ruby/private/toolchains/repository_context.bzl", line 42, column 40, in ruby_repository_context
		interpreter_path = interpreter_path.realpath
Error: /home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/org_ruby_lang_ruby_toolchain/build/bin (No such file or directory)
ERROR: Analysis of target '//tools/rulegen:rulegen' failed; build aborted: /home/patrick/.cache/bazel/_bazel_patrick/1fab284bdcd229840f1565b5f8373614/external/org_ruby_lang_ruby_toolchain/build/bin (No such file or directory)
INFO: Elapsed time: 145.190s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

rules_proto_grpc Version

master

Bazel Version

5.3.2

OS

Arch Linux

Link to Demo Repo

No response

WORKSPACE Content

No response

BUILD Content

No response

Proto Content

No response

Any Other Content

No response

[aaliddell]

Curious, rulegen shouldn't need Ruby at all to run so in theory it shouldn't be built. However, if you are running make rulegen, it could be the initial bazel query that is triggering the Ruby dependency rather than anything rulegen related. How are you running rulegen?

As for the point of continued Ruby support: the Ruby rules give no end of trouble when it comes to CI builds etc, since rules_ruby build the Ruby runtime on every build and somehow break Windows CI IIRC. However, I can't realistically drop them mid v4.x.x release cycle unless it gets really unreasonable to continue.

Whenever v5.x.x of these rules come along, that will be the 'bzlmod version' and will be targeting bzlmod supporting language rulesets only, which at the moment is not too many and is missing some key requirements last I looked. At that point, Ruby's continued inclusion is dependent on whether there is bzlmod Ruby support, which implies rules_ruby gets updated to do so. Since Bazel 6 is out today, that's something I can vaguely start thinking about...

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.