Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arduino-cli core install should install binary tools matching the architecture of the system it is run on #1838

Closed
3 tasks done
imrehorvath opened this issue Aug 16, 2022 · 1 comment
Assignees
Labels
conclusion: invalid Issue/PR not valid topic: code Related to content of the project itself topic: package-management Related to the packaging and managing of the platform/libraries type: enhancement Proposed improvement

Comments

@imrehorvath
Copy link

Describe the request

It would be required that the commands like: arduino-cli core install arduino:avr installs the binary tools in the core for the architecture of the system it is executed on. Eg. the bundled binary gcc in the core should be built for arm64 on Apple silicon Macs and not Intel x86_64.

Describe the current behavior

Currently the arduino-cli core install arduino:avr command installs binary tools pre-built for Intel x86_64 on Apple silicon Macs.

Arduino CLI version

0.26.0

Operating system

macOS

Operating system version

macOS Monterey 12.5

Additional context

No response

Issue checklist

  • I searched for previous requests in the issue tracker
  • I verified the feature was still missing when using the nightly build
  • My request contains all necessary details
@imrehorvath imrehorvath added the type: enhancement Proposed improvement label Aug 16, 2022
@per1234
Copy link
Contributor

per1234 commented Aug 16, 2022

Hi @imrehorvath. Thanks for your request.

Arduino CLI already does pick the best match of the available variants of the tool for the host architecture. If the package maintainer has produced a build for the exact architecture of the host then that will be used. If not, it will use a compatible variant.

The reason you get tools built for macOS x86-64 is because none are available for Apple M1 architecture. If such tool builds are produced, they will start being used without any change in Arduino CLI. Until then, it is better to use the x86-64 variants, which are perfectly compatible with Apple M1 machines courtesy of Rosetta 2.

You can see the tool selection code here:

var (
regexpLinuxArm = regexp.MustCompile("arm.*-linux-gnueabihf")
regexpLinuxArm64 = regexp.MustCompile("(aarch64|arm64)-linux-gnu")
regexpLinux64 = regexp.MustCompile("x86_64-.*linux-gnu")
regexpLinux32 = regexp.MustCompile("i[3456]86-.*linux-gnu")
regexpWindows32 = regexp.MustCompile("i[3456]86-.*(mingw32|cygwin)")
regexpWindows64 = regexp.MustCompile("(amd64|x86_64)-.*(mingw32|cygwin)")
regexpMac64 = regexp.MustCompile("x86_64-apple-darwin.*")
regexpMac32 = regexp.MustCompile("i[3456]86-apple-darwin.*")
regexpMacArm64 = regexp.MustCompile("arm64-apple-darwin.*")
regexpFreeBSDArm = regexp.MustCompile("arm.*-freebsd[0-9]*")
regexpFreeBSD32 = regexp.MustCompile("i?[3456]86-freebsd[0-9]*")
regexpFreeBSD64 = regexp.MustCompile("amd64-freebsd[0-9]*")
)
func (f *Flavor) isExactMatchWith(osName, osArch string) bool {
if f.OS == "all" {
return true
}
switch osName + "," + osArch {
case "linux,arm", "linux,armbe":
return regexpLinuxArm.MatchString(f.OS)
case "linux,arm64":
return regexpLinuxArm64.MatchString(f.OS)
case "linux,amd64":
return regexpLinux64.MatchString(f.OS)
case "linux,386":
return regexpLinux32.MatchString(f.OS)
case "windows,386":
return regexpWindows32.MatchString(f.OS)
case "windows,amd64":
return regexpWindows64.MatchString(f.OS)
case "darwin,arm64":
return regexpMacArm64.MatchString(f.OS)
case "darwin,amd64":
return regexpMac64.MatchString(f.OS)
case "darwin,386":
return regexpMac32.MatchString(f.OS)
case "freebsd,arm":
return regexpFreeBSDArm.MatchString(f.OS)
case "freebsd,386":
return regexpFreeBSD32.MatchString(f.OS)
case "freebsd,amd64":
return regexpFreeBSD64.MatchString(f.OS)
}
return false
}
func (f *Flavor) isCompatibleWith(osName, osArch string) (bool, int) {
if f.isExactMatchWith(osName, osArch) {
return true, 1000
}
switch osName + "," + osArch {
case "windows,amd64":
return regexpWindows32.MatchString(f.OS), 10
case "darwin,amd64":
return regexpMac32.MatchString(f.OS), 10
case "darwin,arm64":
// Compatibility guaranteed through Rosetta emulation
if regexpMac64.MatchString(f.OS) {
// Prefer amd64 version if available
return true, 20
}
return regexpMac32.MatchString(f.OS), 10
}
return false, 0
}
// GetCompatibleFlavour returns the downloadable resource compatible with the running O.S.
func (tr *ToolRelease) GetCompatibleFlavour() *resources.DownloadResource {
return tr.GetFlavourCompatibleWith(runtime.GOOS, runtime.GOARCH)
}
// GetFlavourCompatibleWith returns the downloadable resource compatible with the specified O.S.
func (tr *ToolRelease) GetFlavourCompatibleWith(osName, osArch string) *resources.DownloadResource {
var resource *resources.DownloadResource
priority := -1
for _, flavour := range tr.Flavors {
if comp, p := flavour.isCompatibleWith(osName, osArch); comp && p > priority {
resource = flavour.Resource
priority = p
}
}
return resource
}

@per1234 per1234 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2022
@per1234 per1234 self-assigned this Aug 16, 2022
@per1234 per1234 added the conclusion: invalid Issue/PR not valid label Aug 16, 2022
@per1234 per1234 added topic: code Related to content of the project itself topic: package-management Related to the packaging and managing of the platform/libraries labels Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conclusion: invalid Issue/PR not valid topic: code Related to content of the project itself topic: package-management Related to the packaging and managing of the platform/libraries type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

2 participants