Closed ZhongRuoyu closed 4 months ago
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.
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.
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",
Thanks @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:We can replace them with
ranlib
,nm
, andar
, respectively.This should help to avoid issues like the one spotted in Homebrew/brew#17114.