Invoking `/Users/runner/work/actions/actions/snapshot-master/ruby -rrubygems /Users/runner/work/actions/actions/snapshot-master/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output:
----------------------------------------------------------------------
dyld[42417]: Library not loaded: '/usr/local/lib/libruby.3.3.dylib'
Referenced from: '/Users/runner/work/actions/actions/snapshot-master/ruby'
Reason: tried: '/usr/local/lib/libruby.3.3.dylib' (no such file), '/usr/lib/libruby.3.3.dylib' (no such file)
----------------------------------------------------------------------
Invoking /Users/runner/work/actions/actions/snapshot-master/ruby -rrubygems /Users/runner/work/actions/actions/snapshot-master/bin/gem --backtrace build lib/bundler/bundler.gemspec failed with output:
dyld[42417]: Library not loaded: '/usr/local/lib/libruby.3.3.dylib'
Referenced from: '/Users/runner/work/actions/actions/snapshot-master/ruby'
Reason: tried: '/usr/local/lib/libruby.3.3.dylib' (no such file), '/usr/lib/libruby.3.3.dylib' (no such file)
The problem here is we are trying to launch ${builddir}/ruby before installing it. The ${builddir}/ruby references libruby shared library by absolute path embedded in the binary, but it's not located at the expected path during build-phase.
IIUC this issue can be solved by adding --enable-load-relative, but the use of ${builddir}/ruby in the failing test case test-bundler-parallel might be the root problem. Note that this problem is not only on macOS but could happen if running the test with --enable-shared on Linux or others too.
If the problem will be solved by fixing tests and we will be able to confirm the problem is only for build-phase, re-landing the defaulting change would make sense to me. But if it's more complicated situation, it would be risky to re-land and would be better to postpone to next-next release.