Project

General

Profile

Bug #17021

"arm64" and "arm" are mixed in RbConfig on Apple silicon

Added by watson1978 (Shizuo Fujita) 6 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.8.0dev (2020-07-09T09:14:53Z master addbb7d16e) [arm64-darwin20]
[ruby-core:99097]

Description

When I checked the value of RbConfig::CONFIG on the Apple silicon macOS,e I found "arm64" and "arm" are mixed as following.

$ ruby -v
ruby 2.8.0dev (2020-07-09T09:14:53Z master addbb7d16e) [arm64-darwin20]

$ ruby -e 'require "rbconfig"; pp RbConfig::CONFIG' | grep "arm"
  "/Users/watson/.rbenv/versions/2.8.0/include/ruby-2.8.0/vendor_ruby/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/include/ruby-2.8.0/site_ruby/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/include/ruby-2.8.0/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/lib/ruby/vendor_ruby/2.8.0/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/lib/ruby/site_ruby/2.8.0/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/lib/ruby/2.8.0/arm64-darwin20",
 "sitearch"=>"arm64-darwin20",
 "arch"=>"arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/include/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/include/arm64-darwin20",
 "sitearchlibdir"=>"/Users/watson/.rbenv/versions/2.8.0/lib/arm64-darwin20",
 "archlibdir"=>"/Users/watson/.rbenv/versions/2.8.0/lib/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/lib/ruby/arm64-darwin20",
  "/Users/watson/.rbenv/versions/2.8.0/lib/ruby/arm64-darwin20",
  "Target: arm64-apple-darwin20.0.0\n" +
 "target_cpu"=>"arm64",
 "target"=>"arm64-apple-darwin20",
 "host_cpu"=>"arm",
 "host"=>"arm-apple-darwin20.0.0",
 "build_cpu"=>"arm",
 "build"=>"arm-apple-darwin20.0.0",
  "/Users/watson/.rbenv/versions/2.8.0/lib/ruby/2.8.0/arm64-darwin20",
 "topdir"=>"/Users/watson/.rbenv/versions/2.8.0/lib/ruby/2.8.0/arm64-darwin20"}

"target_cpu" indicates "arm64", however, "host_cpu" has "arm"...

I'd like to know whether this behavior is the right thing.


Related issues

Related to Ruby master - Bug #3565: make test-all fails to runClosedyugui (Yuki Sonoda)07/13/2010Actions

Updated by larskanis (Lars Kanis) 6 months ago

IMHO, "host_cpu" should have "arm64". "arm" looks like a bug to me. Would be nice to get this resolved, since it blocks https://github.com/ffi/ffi/pull/801 .

Updated by Eregon (Benoit Daloze) 2 months ago

This seems a clear bug, at least host_cpu and build_cpu.
arm means 32-bit and is already used e.g. on Linux to mean that.

So it should be arm64 or aarch64.

target_cpu is already arm64 interestingly.
nobu (Nobuyoshi Nakada) Do you know if we could fix that and how?

Updated by nobu (Nobuyoshi Nakada) 2 months ago

As I have no access to Apple silicon machines, can anyone share config.log file on that platform?

Updated by nobu (Nobuyoshi Nakada) 2 months ago

Maybe, uname -m (and tool/config.guess) returns "arm", then RUBY_UNIVERSAL_ARCH replaces target_cpu only?

Updated by nobu (Nobuyoshi Nakada) 2 months ago

I heard that config.guess claims it "arm", while uname -m reports "arm64".

First of all, $host_cpu and others are used only for cross-compilers and nonsense in the other cases.
Why do they matter?

#6

Updated by nobu (Nobuyoshi Nakada) 2 months ago

  • Related to Bug #3565: make test-all fails to run added

Updated by Eregon (Benoit Daloze) 2 months ago

nobu (Nobuyoshi Nakada) wrote in #note-5:

First of all, $host_cpu and others are used only for cross-compilers and nonsense in the other cases.
Why do they matter?

I think RbConfig host_* values should be correct no matter whether cross-compiling or not.

Notably, RbConfig::CONFIG["host_os"] is well known as the portable way to get the OS.
So it follows that RbConfig::CONFIG["host_cpu"] would be the portable way to get the processor architecture.
Both are used here: https://github.com/ffi/ffi/blob/fbe2cf851f426cc55b3b76eca7b10e37aa220b47/lib/ffi/platform.rb

Should another RbConfig::CONFIG key be used? Which one?

Updated by nobu (Nobuyoshi Nakada) about 2 months ago

Eregon (Benoit Daloze) wrote in #note-7:

Should another RbConfig::CONFIG key be used? Which one?

Usually we use target_* instead.

#9

Updated by nobu (Nobuyoshi Nakada) about 2 months ago

  • Status changed from Open to Closed

Applied in changeset git|43a9a974e276dc49b03ec81ccace0adb534a3d20.


[Bug #17021] Make host_* values consistent with target_*

Also available in: Atom PDF