January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:119621] [Ruby master Bug#20816] Potential regression in Ruby 3.3.x (compared with 3.1 and 3.2) regarding fast syscalls and multi-threading.
by adrienjarthon (Adrien Jarthon) 14 Jan '25

14 Jan '25

Issue #20816 has been reported by adrienjarthon (Adrien Jarthon). ---------------------------------------- Bug #20816: Potential regression in Ruby 3.3.x (compared with 3.1 and 3.2) regarding fast syscalls and multi-threading. https://bugs.ruby-lang.org/issues/20816 * Author: adrienjarthon (Adrien Jarthon) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ok I'm sorry in advance if this is not really a regression (maybe it's the cost to pay for other improvements) but it still showed as a 30% performance drop in my benchmark so I think it may be worth a look. For the full story about how I came down this rabbit hole I just wrote a blog post to avoid cluttering the issue: https://updown.io/blog/weird-results-comparing-ruby-3-1-3-2-3-3-with-jemall… (please read it first) Here I'm gonna put my last findings and the smallest reproducible example I was able to write. So basically I noticed that quick syscalls (at least with a good SSD) like `File.exists?` or `File.mtime`, when used in a multi-threaded environement (Sidekiq in my initial testing but I reduced it to a few Thread.new) are significantly slower in 3.3.x (tested with the same results on 3.3.0, 3.3.2 and 3.3.5 for the moment) in comparison with 3.1.2 or 3.2.5: about twice as slow. These syscalls are heavily used by the Rails Reloader which is how it had such a huge impact (30%) in my testing. Here is the small reproduction script I wrote: ``` ruby #!/usr/bin/env ruby GC.disable # just to make sure it doesn't skew results THREADS = (ARGV.first || 10).to_i # choose thread count from CLI N = 10_000_000 # to make the test longer or shorter puts "Ruby #{RUBY_VERSION} / YJIT: #{RubyVM::YJIT.enabled?} / #{THREADS} Threads" Array.new(THREADS).map do Thread.new do (N/THREADS).times { File.mtime(__FILE__) } end end.each(&:join) puts "#{N} calls completed" ``` The goal is just to run a lot of fast syscalls, in various number of threads, and here are the numbers on my machine: |Threads\Ruby|3.1.2 |3.3.5 | |--|--|--| |1 | 13.7s | ✅ 14.2s | |2 | 9.7s | ⚠️ 33.4s | |4 | 23.2s | ⚠️ 37.0s | |8 | 21.8s | ⚠️ 39.7s | |16 | 23.1s | ⚠️ 41.5s | (more numbers in the [blog post](https://updown.io/blog/weird-results-comparing-ruby-3-1-3-2-3-3-with-jemalloc-and-yjit)) I suspected the [new N:M thread scheduler introduced in 3.3](https://github.com/ruby/ruby/pull/8629), even though it's "disabled" by default on the main Ractor, thinking maybe these changes degraded a bit this (quite specific scenario). So I gave a quick try with the feature ENABLED, to see if it would at least change anything and it did ! (though not was I expected): |Threads\Ruby|3.1.2 |3.3.5 | 3.3.5 with RUBY_MN_THREADS=1 | |--|--|--|--| |1 | 13.7s | 14.2s | 14.5s ✅ | |2 | 9.7s | ⚠️ 33.4s | 12.3s 🎉 | |4 | 23.2s | ⚠️ 37.0s | 40.5s 🧐 | |8 | 21.8s | ⚠️ 39.7s | 37.9s 🧐 | |16 | 23.1s | ⚠️ 41.5s | 36.3s 🧐 | (I can make graphs for these numbers if it helps) Now I'm a bit stuck in my investigation, I'm not sure what change in 3.3 caused this (the new thread scheduler is a good lead IMO) or if it even is a regression. Maybe this downside is innevitable for other benefits? I am happy to contribute more time to this issue and perform more tests but I would need some guidance on what could be interesting to test, from people who understand a bit better than me how this works internally. Thanks ! (and sorry for the long read) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:112005] [Ruby master Bug#19374] Issue with Ractor.make_shareable with curried procs
by luke-gru (Luke Gruber) 14 Jan '25

14 Jan '25

Issue #19374 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19374: Issue with Ractor.make_shareable with curried procs https://bugs.ruby-lang.org/issues/19374 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This works, but shouldn't: ```ruby class Worker def start(&blk) blk = blk.curry # bug in ruby allows sharing of non-shareable proc Ractor.make_shareable(blk) @ractor = Ractor.new(blk) do |b| main = b.call p "from ractor: #{main}" end end def work @ractor.take end end worker = Worker.new a = self # unshareable main object p "from main: #{a}" worker.start { a } worker.work ``` The curried proc has a reference to the original proc and it's not checked for shareability. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:118284] [Ruby master Misc#20575] Syntax Moratorium til 3.4
by matz (Yukihiro Matsumoto) 14 Jan '25

14 Jan '25

Issue #20575 has been reported by matz (Yukihiro Matsumoto). ---------------------------------------- Misc #20575: Syntax Moratorium til 3.4 https://bugs.ruby-lang.org/issues/20575 * Author: matz (Yukihiro Matsumoto) * Status: Open ---------------------------------------- Hi, As some may remember from the closing keynote at RubyKaigi, we are introducing Syntax Moratorium to support fair development of parsers. During the Syntax Moratorium period, new syntactical changes will be suspended (changes not includes bug fixes, of course). The moratorium period is scheduled to end with the release of 3.4, since the respective parser developers told us they did not need a very long period of time. Matz. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119944] [Ruby master Feature#20899] Reconsider adding `Array#find_map`
by toy (Ivan Kuchin) 12 Jan '25

12 Jan '25

Issue #20899 has been reported by toy (Ivan Kuchin). ---------------------------------------- Feature #20899: Reconsider adding `Array#find_map` https://bugs.ruby-lang.org/issues/20899 * Author: toy (Ivan Kuchin) * Status: Open ---------------------------------------- I would like to retry proposing method `Array#find_map` that was rejected in [8421](https://bugs.ruby-lang.org/issues/8421) which happened before introduction of `filter_map` in [15323](https://bugs.ruby-lang.org/issues/15323). It would make code nicer whenever there is a need to get the first truthy result of applying some code. Adapting examples from `filter_map` documentation, but if I need only the first value: ```rb (1..9).find_map {|i| i * 2 if i.even? } # => 4 {foo: 0, bar: 1, baz: 2}.find_map {|key, value| key if value.even? } # => :foo ``` Or an example of getting match group for first successful match: ```rb list = ['some 123', 'list 234', 'of 345', 'strings 456'] list.find_map{ |s| s[/\Aof (\d+)\z/, 1] } # => "345" ``` Currently I imagine either more code and/or inefficiency (extra calls and/or objects): ```rb # code called twice list.find{ |s| s[/\Aof (\d+)\z/, 1] }&.then{ |s| s[/\Aof (\d+)\z/, 1] } # => "345" # more logic result = nil list.each do |s| break if (result = s[/\Aof (\d+)\z/, 1]) end result # => "345" # or result = nil list.find do |s| result = s[/\Aof (\d+)\z/, 1] end result # => "345" # extra calls for items which come after item that we were looking for list.map{ |s| s[/\Aof (\d+)\z/, 1] }.find{ _1 } # => "345" # using lazy list.lazy.map{ |s| s[/\Aof (\d+)\z/, 1] }.find{ _1 } # => "345" # or as suggested by @alexbarret in https://bugs.ruby-lang.org/issues/8421?tab=history#note-7 list.lazy.filter_map{ |s| s[/\Aof (\d+)\z/, 1] }.first # => "345" # using tricks, as suggested by @zverok in https://bugs.ruby-lang.org/issues/8421?tab=history#note-4 list.find{ |s| result = s[/\Aof (\d+)\z/, 1] and break result } # => "345" ``` Implementation in ruby can be: ```rb Enumerable.class_eval do def find_map(&block) each do |element| block_result = block.call(element) return block_result if block_result end nil end end ``` An example from another language - scala method [`collect`](https://www.scala-lang.org/api/3.5.2/scala/collection/ArrayOps.html#collect-68e) works alike `filter_map` and [`collectFirst`](https://www.scala-lang.org/api/3.5.2/scala/collection/ArrayOps.html#collectFirst-25d) would be like `find_map`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:119272] [Ruby master Feature#20757] Make rb_tracearg_(parameters|eval_script|instruction_sequence) public C-API
by richardboehme 11 Jan '25

11 Jan '25

Issue #20757 has been reported by richardboehme (Richard Böhme). ---------------------------------------- Feature #20757: Make rb_tracearg_(parameters|eval_script|instruction_sequence) public C-API https://bugs.ruby-lang.org/issues/20757 * Author: richardboehme (Richard Böhme) * Status: Open ---------------------------------------- **Abstract** As a C-extension developer when using tracepoints I include "ruby/debug.h". This includes most of TracePoint's API but it seems like the C-equivalents for TracePoint#parameters, TracePoint#eval_script and TracePoint#instruction_sequence are missing/not being exported in the header. **Background** Most APIs like rb_tracearg_return_value are exported in "ruby/debug.h". If I understand correctly, the implementations for those methods are located in "ruby/vm_trace.c". The following methods implemented in "ruby/vm_trace.c" are missing in "ruby/debug.h": * rb_tracearg_parameters * rb_tracearg_eval_script * rb_tracearg_instruction_sequence **Proposal** I propose to add those methods to "ruby/debug.h". From my limiting understanding the change should be simple and not break backward compatibility, because we'd only need to add those function declarations to "ruby/debug.h". I'd be open to contribute this change if it was approved. **Use cases** I'm implementing a method call tracer for Ruby using the C-extension API. I wanted to get information about the parameters that the called method receives. When writing in Ruby this can be done using the TracePoint#parameters method, but I could not find the equivalent C-API. A workaround is to retrieve the method object (using the method_id) and check the method parameters. **See also** * Implementation of TracePoint#parameters in #14694 * Implementation of TracePoint#eval_script and TracePoint#instruction_sequence in #15287 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120545] [Ruby master Feature#21015] Add in a `-g` flag, like `-s` but with a few more quality of life features
by sampersand2 (Sam Westerman) 11 Jan '25

11 Jan '25

Issue #21015 has been reported by sampersand2 (Sam Westerman). ---------------------------------------- Feature #21015: Add in a `-g` flag, like `-s` but with a few more quality of life features https://bugs.ruby-lang.org/issues/21015 * Author: sampersand2 (Sam Westerman) * Status: Open ---------------------------------------- Add in a `-g` flag, like `-s` but with a few more QOL features ## TL;DR ([PR](https://github.com/ruby/ruby/pull/12526).) Ruby's `-s` flag has quite a few shortfalls that make it difficult to use when writing scripts . A new `-g` flag will fix it: ```shell # Support `-abc` as a shorthand for `-a -b -c` ruby -ge'p [$a, $b, $c]' -- -abc #=> [1, 1, 1] # Support `-vvv` as a shorthand for `-v=3` ruby -ge'p $v' -- -vvv #=> 3 # Support things other than strings: ruby -ge'p [$n, $f]' -- -n90 -f=false #=> [90, false] # long-forms don't have a leading `_` ruby -ge'p $foo_bar' -- --foo-bar #=> true ``` I propose a `-g` flag to fix it. # Background: What is `-s` Ruby's `-s` flag is an extremely helpful feature when writing short little scripts to set config options; it automatically processes `ARGV` and removes leading "flags" for you, assigning them to global variables. ```ruby #!/bin/ruby -s # echo, ruby-style! If `-n` is given, no newline is printed print ARGV.join(' '), ($n ? "" : "\n") ``` While `-s` is significantly less powerful than `OptionParse`, or even via just parsing options yourselves, it's **incredibly** useful when writing simple little scripts where the option parsing code would be longer than the script itself. ## Problem 1 (The big one): No support for chained short-form flags The biggest problem with `-s` is that it doesn't let you concatenate short-form flags together: conventionally, `./myprogram -x -y -z` should be the same as `./myprogram -xyz`. However, if `./myprogram` were a ruby program using `-s`, you'd end up with the global variable `$xyz`. Short scripts that use `-s` to parse options thus need to add the following code to handle all different permutations of `-x`, `-y`, and `-z`: ```ruby # Handle all permutations of `-xyz` $xyz || $xzy || $yxz || $yzx || $zxy || $zyx and $x=$y=$z=true # Handle only two options given $xy || $yx and $x=$y=true $xz || $zx and $x=$z=true $yz || $zy and $y=$z=true ``` Four flags becomes even worse: ```ruby $wxyz || $wxzy || $wyxz || $wyzx || \ $wzxy || $wzyx || $xwyz || $xwzy || \ $xywz || $xyzw || $xzwy || $xzyw || \ $ywxz || $ywzx || $yxwz || $yxzw || \ $yzwx || $yzxw || $zwxy || $zwyx || \ $zxwy || $zxyw || $zywx || $zyxw and $w=$x=$y=$z=true $wxy || $wyx || $xwy || $xyw || $ywx || $yxw and $w=$x=$y=true $wxz || $wzx || $xwz || $xzw || $zwx || $zxw and $w=$x=$z=true $wyz || $wzy || $ywz || $yzw || $zwy || $zyw and $w=$y=$z=true $xyz || $xzy || $yxz || $yzx || $zxy || $zyx and $x=$y=$z=true $wx || $xw and $w=$x=true $wy || $yw and $w=$y=true $wz || $zw and $w=$z=true $xy || $yx and $x=$y=true $xz || $zx and $x=$z=true $yz || $zy and $y=$z=true ``` This is a huge problem for simple little scripts, as they're forced into an uncomfortable choice: 1. Use `OptionParser`, which is very much overkill for tiny scripts 2. Break from unix standards and require passing short-forms individually (i.e. `./program.rb -x -y -z`) 3. Do the cumbersome permutation checks as shown above 4. Give up on flags all together and use environment variables. None of these options are great, *especially* because Ruby's all about programmer happiness and none of these options spark joy. ## Problem 2: All values are `Strings` Less important than the short-form issue is that all values provided to flags become Strings (e.g. `ruby -se'p $foo' -- -foo=30` yields `"30"`). While this can be solved by `$foo = $foo&.to_i` somewhere early on, it's verbose: ```ruby #!ruby -s # Very simple benchmarking program $log_level = $log_level&.to_i $amount = $amount&.to_i $timeout = $timeout&.to_i $precision = $precision&.to_i $amount.times do |iter| start = Time.now $log_level > 1 and puts "[iteration: #{iter}] running: #{ARGV}" pipe = IO.popen ARGV unless select [pipe], nil, nil, $timeout warn "took too long!" next end printf "%0.#{$precision}f", Time.now - start end ``` Moreover, there's no way to create a falsey flag other than just omitting it, which can make interacting with `-s` scripts somewhat irritating: ```ruby # Have to use `*[... ? ... : nil].compact`, otherwise # we'd end up passing an empty string/nil as an arg system("./myprogram.rb", *[enable_foo ? "--foo" : nil].compact) ``` A better solution would be to allow for `--foo=false` or `--foo=true`, and then parse the `false`/`true`. ## Problem 3 (Minor): Long-form options have a leading `_` Long-form options, such as `--help`, have a leading `_` appended to them (to disambiguate them from `-help`). While it can be worked around (either `alias $help $_help` or just using `$_help` directly), it's irritating enough that I've been known to just force end-users to use `-help`. This diverges from the common "long-form options should have two dashes in front of them," further making ruby scripts with `-s` a bit awkward to use ## Problem 4 (Minor): Repeated flags aren't supported Sometimes it's useful to know how many times a flag was repeated, such as `-vvv` to enable "very very verbose mode": Using `-s` you must do ```ruby is_verbose = $v ? 1 : ($vv ? 2 : ($vvv ? 3 : ($vvvv ? 4 : ...))) ``` While I've yet to see a use-case for repeating a flag beyond three or four times, having to manually enumerate everything out is, again, a bit of a pain. # Solution: Add a new `-g` flag, which supports all this I propose the addition of a new command-line flag, `-g`, which adds in a new form of argument parsing that solves all these issues. [PR](https://github.com/ruby/ruby/pull/12526) ## Overview: ```shell ruby -ge'p [$a, $b, $c]' -- -abc #=> [1, 1, 1] ruby -ge'p $d' -- -d90 #=> 90 ruby -ge'p [$d, $e]' -- -d90e=foo #=> [90, "foo"] ruby -ge'p [$hi, $foo_bar]' -- --hi --foo-bar=false #=> [true, false] ruby -ge'p $x' -- -xxx #=> 3 # Putting it together now, lol. ruby -g -e'p [$a, $b, $c, $d, $e, $world]' -- -abbcd90e=hello --world=false # => [true, 2, true, 90, "hello", false]``` ``` # Open Questions ## How should supplying both `-g` and `-s` work? This is the first flag that'd directly conflict with another command-line flag, so what should be done when both `-g` and `-s` are given (such as `ruby -gs -e'p $x' -- -x=9`). Here's the options as I see them: 1. Use to last supplied flag (in the example `-s`). This'd act like how incompatible flags work in other utilities 2. Always use `-g`, as it can be considered a sort-of a "super set" of `-s`. 3. Emit a warning, and then do either `1.` or `2.` 4. Emit an error, and then do either `1.` or `2.` I'm personally partial to emitting a warning on `-W2`, and then using the last supplied flag, however I could be convinced to any of the options ## Should `-x` do `$x = true` or `$x = 1` I personally'd like `-x` to be `true`, just like `-s`. However, this conflicts with `-xx` yielding `2`, as `log if $x > 1` wouldn't work. Since `1` is truthy, I've defaulted `-x` to `1`, but I could be convinced to remove it (and even remove the entire `-xx` thing if there was a good argument.) ## Why introduce a new flag? Why name it `-g`? I think adding in a new flag makes sense: `-g` is a modification of `-s`, so it naturally should be a new flag. (Attempting to shoehorn these options into `-s` would be a nightmare.) I briefly considered using `-ss` as the flag name, to make it clear that it was a modification of `-s`, however that'd be the first two-character short flag and I didn't want to introduce that. (And, it'd be pretty ironic as a large portion of the impetus behind `-g` is to parse short flags, which `-ss` isn't :-P.) As for `-g` specifically, I considered `-o` for "options" (nixed because most utilities use it for "output," and I didn't want the cognitive overload), and `-f` for "flags" (nixed because some utilities use it to mean "file," and ruby might use it in the future.) I picked `-g` because it's short for "globals" or "getflags". # Alternatives (TODO) ## Continue using `-s` (TODO) not great, as shown above # Prior art (TODO) Perl has `-s`, and it works like Ruby's `-s`. IDK of any other languages which even attempt this. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120602] [Ruby master Misc#21025] What's the default encoding of `String.new`?
by deivid 10 Jan '25

10 Jan '25

Issue #21025 has been reported by deivid (David Rodríguez). ---------------------------------------- Misc #21025: What's the default encoding of `String.new`? https://bugs.ruby-lang.org/issues/21025 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In the documentation (https://docs.ruby-lang.org/en/3.4/encodings_rdoc.html#label-String+Encoding) I see a good explanation of default string encodings: ![](Captura%20de%20pantalla%202025-01-10%20a%20las%2017.53.06.png) However, it does not mention `String.new` without an argument, which is the one case where I see inconsistent behavior. ``` irb(main):001> "".encoding => #<Encoding:UTF-8> irb(main):002> String.new("").encoding => #<Encoding:UTF-8> irb(main):003> String.new(a="").encoding => #<Encoding:UTF-8> irb(main):004> String.new.encoding => #<Encoding:BINARY (ASCII-8BIT)> ``` Should this be documented or changed? ---Files-------------------------------- Captura de pantalla 2025-01-10 a las 17.53.06.png (139 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120584] [Ruby master Bug#21022] The --with-modular-gc= option is a
by vo.x (Vit Ondruch) 10 Jan '25

10 Jan '25

Issue #21022 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #21022: The --with-modular-gc= option is a https://bugs.ruby-lang.org/issues/21022 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM +GC [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Just experimenting a bit with the `--with-modular-gc=` if it is worth of enabling in Fedora, but I somehow cannot wrap my head around that. What is the intended configuration? From Fedora POV, we have Ruby installed somewhere in `/usr`, which can only be managed by RPM. I don't think that we would like to package any additional GC. But if we wanted, we would likely installed it outside of the default Ruby directory structure. We would also like our users to experiment. So they would ideally have their GC built somewhere in their HOME. In that case, I'd expect that something like `RUBY_GC_LIBRARY=/home/johndoe/path/to/gc/gc.so ruby -e 'puts "Hello custom GC"'` would be command to run. But it does not seems that the current configuration option / env variables have anything like this in their mind. Actually I wonder why the GC is not packaged as gem? Maybe RubyGems are late to the party to load the GC early enough. But they still would be nice method of distribution. From #20860 I understand that the MMTk is experimental. But from the Ruby 3.4, the Modular GC seems to be as something users might want. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120594] [Ruby master Bug#21023] Unintentional ruby/spec capi extension build twice
by hsbt (Hiroshi SHIBATA) 10 Jan '25

10 Jan '25

Issue #21023 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21023: Unintentional ruby/spec capi extension build twice https://bugs.ruby-lang.org/issues/21023 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I faced `building spec/ruby/optional/capi/ext/` build twice sometimes like: ``` ❯ make -j revision.h updated generating arm64-darwin24-fake.rb arm64-darwin24-fake.rb updated rbconfig.rb unchanged generating encdb.h generating enc.mk creating verconf.h verconf.h updated compiling loadpath.c encdb.h unchanged making srcs under enc generating transdb.h linking static-library libruby.3.5-static.a transdb.h unchanged linking shared-library libruby.3.5.dylib generating makefiles ext/configure-ext.mk building spec/ruby/optional/capi/ext/array_spec.bundle building spec/ruby/optional/capi/ext/bignum_spec.bundle building spec/ruby/optional/capi/ext/basic_object_spec.bundle building spec/ruby/optional/capi/ext/binding_spec.bundle building spec/ruby/optional/capi/ext/boolean_spec.bundle building spec/ruby/optional/capi/ext/class_id_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/class_spec.bundle building spec/ruby/optional/capi/ext/class_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/data_spec.bundle building spec/ruby/optional/capi/ext/complex_spec.bundle building spec/ruby/optional/capi/ext/constants_spec.bundle building spec/ruby/optional/capi/ext/debug_spec.bundle building spec/ruby/optional/capi/ext/encoding_spec.bundle building spec/ruby/optional/capi/ext/enumerator_spec.bundle building spec/ruby/optional/capi/ext/fiber_spec.bundle building spec/ruby/optional/capi/ext/file_spec.bundle building spec/ruby/optional/capi/ext/exception_spec.bundle building spec/ruby/optional/capi/ext/fixnum_spec.bundle building spec/ruby/optional/capi/ext/float_spec.bundle building spec/ruby/optional/capi/ext/gc_spec.bundle building spec/ruby/optional/capi/ext/globals_spec.bundle building spec/ruby/optional/capi/ext/hash_spec.bundle building spec/ruby/optional/capi/ext/io_spec.bundle building spec/ruby/optional/capi/ext/numeric_spec.bundle building spec/ruby/optional/capi/ext/integer_spec.bundle building spec/ruby/optional/capi/ext/kernel_spec.bundle building spec/ruby/optional/capi/ext/module_spec.bundle building spec/ruby/optional/capi/ext/marshal_spec.bundle building spec/ruby/optional/capi/ext/module_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/language_spec.bundle building spec/ruby/optional/capi/ext/mutex_spec.bundle building spec/ruby/optional/capi/ext/symbol_spec.bundle building spec/ruby/optional/capi/ext/time_spec.bundle building spec/ruby/optional/capi/ext/string_spec.bundle building spec/ruby/optional/capi/ext/proc_spec.bundle building spec/ruby/optional/capi/ext/thread_spec.bundle building spec/ruby/optional/capi/ext/object_spec.bundle building spec/ruby/optional/capi/ext/rbasic_spec.bundle building spec/ruby/optional/capi/ext/range_spec.bundle building spec/ruby/optional/capi/ext/rational_spec.bundle building spec/ruby/optional/capi/ext/util_spec.bundle building spec/ruby/optional/capi/ext/st_spec.bundle building spec/ruby/optional/capi/ext/tracepoint_spec.bundle building spec/ruby/optional/capi/ext/regexp_spec.bundle building spec/ruby/optional/capi/ext/struct_spec.bundle building spec/ruby/optional/capi/ext/typed_data_spec.bundle making enc making trans ext/configure-ext.mk updated making encs generating makefile exts.mk exts.mk unchanged compiling version.c linking miniruby ln -sf ../../rbconfig.rb .ext/arm64-darwin24/rbconfig.rb builtin_binary.inc updated ae4db3fa410991261f4203ac62ff7aa8eb3959967203d43e69af30c1ea1423fe builtin_binary.inc compiling builtin.c linking static-library libruby.3.5-static.a linking shared-library libruby.3.5.dylib building spec/ruby/optional/capi/ext/array_spec.bundle building spec/ruby/optional/capi/ext/basic_object_spec.bundle building spec/ruby/optional/capi/ext/bignum_spec.bundle building spec/ruby/optional/capi/ext/binding_spec.bundle building spec/ruby/optional/capi/ext/boolean_spec.bundle building spec/ruby/optional/capi/ext/class_spec.bundle building spec/ruby/optional/capi/ext/class_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/class_id_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/complex_spec.bundle building spec/ruby/optional/capi/ext/constants_spec.bundle building spec/ruby/optional/capi/ext/debug_spec.bundle building spec/ruby/optional/capi/ext/data_spec.bundle building spec/ruby/optional/capi/ext/encoding_spec.bundle building spec/ruby/optional/capi/ext/enumerator_spec.bundle building spec/ruby/optional/capi/ext/exception_spec.bundle building spec/ruby/optional/capi/ext/fiber_spec.bundle building spec/ruby/optional/capi/ext/fixnum_spec.bundle building spec/ruby/optional/capi/ext/file_spec.bundle building spec/ruby/optional/capi/ext/gc_spec.bundle building spec/ruby/optional/capi/ext/float_spec.bundle building spec/ruby/optional/capi/ext/hash_spec.bundle building spec/ruby/optional/capi/ext/integer_spec.bundle building spec/ruby/optional/capi/ext/globals_spec.bundle building spec/ruby/optional/capi/ext/language_spec.bundle building spec/ruby/optional/capi/ext/io_spec.bundle building spec/ruby/optional/capi/ext/kernel_spec.bundle building spec/ruby/optional/capi/ext/marshal_spec.bundle building spec/ruby/optional/capi/ext/module_spec.bundle building spec/ruby/optional/capi/ext/module_under_autoload_spec.bundle building spec/ruby/optional/capi/ext/mutex_spec.bundle building spec/ruby/optional/capi/ext/numeric_spec.bundle building spec/ruby/optional/capi/ext/object_spec.bundle building spec/ruby/optional/capi/ext/proc_spec.bundle building spec/ruby/optional/capi/ext/range_spec.bundle building spec/ruby/optional/capi/ext/regexp_spec.bundle building spec/ruby/optional/capi/ext/rational_spec.bundle building spec/ruby/optional/capi/ext/string_spec.bundle building spec/ruby/optional/capi/ext/rbasic_spec.bundle building spec/ruby/optional/capi/ext/struct_spec.bundle building spec/ruby/optional/capi/ext/tracepoint_spec.bundle building spec/ruby/optional/capi/ext/st_spec.bundle building spec/ruby/optional/capi/ext/symbol_spec.bundle building spec/ruby/optional/capi/ext/thread_spec.bundle building spec/ruby/optional/capi/ext/time_spec.bundle building spec/ruby/optional/capi/ext/util_spec.bundle building spec/ruby/optional/capi/ext/typed_data_spec.bundle linking ruby ``` @nobu said "It's triggered with `linking shared-library libruby.3.5.dylib`". It seems unintentional behavior. we should avoid that. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:117826] [Ruby master Bug#20480] Complie failure for unable to configure NET_LUID using msys2 mingw64-gcc
by nekoyama32767 (Jinsong Yu) 10 Jan '25

10 Jan '25

Issue #20480 has been reported by nekoyama32767 (Jinsong Yu). ---------------------------------------- Bug #20480: Complie failure for unable to configure NET_LUID using msys2 mingw64-gcc https://bugs.ruby-lang.org/issues/20480 * Author: nekoyama32767 (Jinsong Yu) * Status: Open * ruby -v: ruby 3.4.0dev (2024-05-10T04:54:31Z master 2f915e729a) [x64-mingw32] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Master commit:`2f915e729ac8c66f4009f4b28a57773923d7e7d1` NET_LUID is not successfully checked in win32 configure. When try to compile in msys2 mingw64-gcc there will be a error message like follow. ``` win32/win32.c:4365:7: error: conflicting types for 'NET_LUID'; have 'struct <anonymous>' 4365 | } NET_LUID; | ^~~~~~~~ In file included from D:/msys64/mingw64/include/iptypes.h:17, from D:/msys64/mingw64/include/iphlpapi.h:17, from ./include/ruby/win32.h:40, from ./include/ruby/internal/dosish.h:38, from ./include/ruby/defines.h:78, from ./include/ruby/ruby.h:25, from win32/win32.c:24: D:/msys64/mingw64/include/ifdef.h:106:3: note: previous declaration of 'NET_LUID' with type 'NET_LUID' 106 | } NET_LUID, *PNET_LUID; | ^~~~~~~~ ``` Mingw64-gcc has NET_LUID, when comment out line 4357-line 4367 in `win32/win32.c` in follow, compile will be successed. ``` #ifndef HAVE_TYPE_NET_LUID typedef struct { uint64_t Value; struct { uint64_t Reserved :24; uint64_t NetLuidIndex :24; uint64_t IfType :16; } Info; } NET_LUID; #endif ``` mingw64-gcc version ``` gcc --version gcc.exe (Rev4, Built by MSYS2 project) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` -- https://bugs.ruby-lang.org/

2 3