portable-ruby: fix more compiler toolchain references

[ZhongRuoyu]

We already get rid of the compiler shim references in rbconfig.rb, but there are still some more that may not be valid on the target system:

$ brew ruby -e 'p RbConfig::CONFIG.select { |k, v| v.match? /gcc-(.*)-\d+/ }'
{"RANLIB"=>"gcc-ranlib-11", "NM"=>"gcc-nm-11", "AR"=>"gcc-ar-11"}

We can replace them with ranlib, nm, and ar, respectively.

This should help to avoid issues like the one spotted in Homebrew/brew#17114.

[ParadoxV5]

Maybe the solution for the core problem is to have the Ruby builder use these agnostic names in the first place?

---

Interesting. Portable Ruby. I know RubyInstaller2 for Windows is portable, but never knew that Mac and Linux also have this.

[ZhongRuoyu]

Maybe the solution for the core problem is to have the Ruby builder use these agnostic names in the first place?

That's possible too; they can be overridden with ENV["AR"], etc. Those gcc-* tools are wrappers that pass the LTO plugin, although we don't seem to have enabled LTO.

Interesting. Portable Ruby. I know RubyInstaller2 for Windows is portable, but never knew that Mac and Linux also have this.

This is for Homebrew's internal use only; we don't advertise it or provide download or support for general usage like RubyInstaller or others do.

[Bo98]

Maybe the solution for the core problem is to have the Ruby builder use these agnostic names in the first place?

Same has applied to cc for years - this is just an extension to that workaround to cover ar too. In our particular case, the host compiler doesn't necessarily match the target compiler, so we replace gcc-XX references with cc etc.

On macOS, this generally isn't a problem since clang will always exist if you have macOS SDK installed. And we do not see full paths like you are seeing in that prism issue:

"AR" => "ar",
"CC" => "clang",

[MikeMcQuaid]

Thanks @ZhongRuoyu!