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

Add aarch64-apple-darwin target #2099

Closed
wants to merge 1 commit into from
Closed

Add aarch64-apple-darwin target #2099

wants to merge 1 commit into from

Conversation

arbourd
Copy link

@arbourd arbourd commented Dec 12, 2021

Adds a build target aarch64-apple-darwin to the release steps.

Closes #1737

@arbourd arbourd changed the title Add macOS-arm64 build Add aarch64-apple-darwin target Dec 12, 2021
Copy link
Owner

@BurntSushi BurntSushi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this also needs to be added to the ci workflow, otherwise macos-arm won't be tested on PRs.

@arbourd
Copy link
Author

arbourd commented Dec 15, 2021

Not 100% sure why this is failing (not a Rust dev):

     Running `/Users/runner/work/ripgrep/ripgrep/target/aarch64-apple-darwin/debug/deps/globset-5ccc9bf3313e73b3`
error: test failed, to rerun pass '-p globset --lib'

Caused by:
  could not execute process `/Users/runner/work/ripgrep/ripgrep/target/aarch64-apple-darwin/debug/deps/globset-5ccc9bf3313e73b3` (never executed)

Guessing we're building globset for aarch64 and trying to execute it? The macOS runners should be able to build arm64 binaries but don't think they'd be able to execute anything.

@BurntSushi
Copy link
Owner

The macOS runners should be able to build arm64 binaries but don't think they'd be able to execute anything.

How come? If that's truly the case, then I think adding macOS/arm to CI is premature.

@arbourd
Copy link
Author

arbourd commented Dec 15, 2021

The Actions runners are amd64. I can easily build a Go or Swift arm64 binary on my intel amd64 machine, but if I try to execute that binary it will fail (unless it's universal, which is basically both the binaries squeezed into the same bin at double the size).

Homebrew uses its own arm64 runner VMs to build ripgrep binaries (it runs tests after that would require the runtime).

If that's truly the case, then I think adding macOS/arm to CI is premature.

True, but I'd still love to see an official binary packaged here, rather than having to rely on just Homebrew/source. I'd have to check that the bin in release.yml actually work though, haha.

@BurntSushi
Copy link
Owner

Basically, managing the release is already really time consuming work. Adding more release targets that are difficult to verify isn't great IMO. I'd be open to it, but I'm really not the right point-of-contact to help debug unfortunately. I'm neither a macOS nor an arm user. So if others want to chip in here and do the leg work to make sure this is all working properly, I'd be willing to bring it in. But that also means testing that the release workflow works (probably in another repo).

For other linux/arm builds, I believe we use Cross to both build binaries and run tests. Ideally we could do that here, although I doubt the infrastructure on macOS exists for such a thing.

Given the popularity of macOS/arm, like I said, I'd be willing to bring this in, but I think others will need to put in the work here.

@arbourd
Copy link
Author

arbourd commented Dec 15, 2021

I'm neither a macOS nor an arm user. So if others want to chip in here and do the leg work to make sure this is all working properly, I'd be willing to bring it in. But that also means testing that the release workflow works (probably in another repo).

Totally understand. I can get the release working on my fork and verify if the binary functions. When you say "testing that the release workflow works" do you mean constantly or just the first time 😅

Ideally we could do that here, although I doubt the infrastructure on macOS exists for such a thing.

I think to get the full workflow in here we'd need actions/runner-images#2187 (comment)

Given the popularity of macOS/arm, like I said, I'd be willing to bring this in, but I think others will need to put in the work here.

Happy to help here. I don't even have an arm64 Mac yet but I will eventually and when I do I wanna be able to curl here.

Thank you for all your work on ripgrep. It's awesome and I use it everywhere ❤️

@arbourd
Copy link
Author

arbourd commented Dec 15, 2021

Updated the macos runner to macos-11 (latest is still 10.15). I don't think that'll fix it but arm64 cross compilation support should be better.

- build: macos-arm
os: macos-11
rust: nightly
target: aarch64-apple-darwin
Copy link
Contributor

@arcsi42 arcsi42 Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried running the ci workflow without this target specified, so cross isn't used for building, and all the runs have passed so far. Not sure if that's helpful.

Suggested change
target: aarch64-apple-darwin

https://github.com/arcsi42/ripgrep/actions/runs/1725214380

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without the target is it building a universal binary?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does cargo build universal binaries on Apple silicon? I'm not sure if it does yet, rust-lang/cargo#8875.
But we could use lipo in a macos-11 runner to merge both the x86_64 and arm64/aarch64 builds.
I have successful runs using lipo: https://github.com/arcsi42/ripgrep/actions/runs/1729830482, https://github.com/arcsi42/ripgrep/releases/tag/TEST-0.0.3

@arcsi42
Copy link
Contributor

arcsi42 commented Jan 20, 2022

I have also tried modifying the release.yml workflow and seems to be working with the macos-11 runner. Here is the passing workflow run: https://github.com/arcsi42/ripgrep/actions/runs/1725448592.

And the built artifacts could be tested by someone with an Arm Mac machine: https://github.com/arcsi42/ripgrep/releases/tag/TEST-0.0.2.

At least the file format looks okay:

$ file ./ripgrep-TEST-0.0.2-aarch64-apple-darwin/rg 
./ripgrep-TEST-0.0.2-aarch64-apple-darwin/rg: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

@ellioseven
Copy link

@arcsi42 Can confirm I was able to get the version from the binary on my M1 Mac:

image

@arcsi42
Copy link
Contributor

arcsi42 commented Jan 21, 2022

I have also built a universal binary using lipo on a macos-11 runner: https://github.com/arcsi42/ripgrep/actions/runs/1729830482, can be downloaded from https://github.com/arcsi42/ripgrep/releases/tag/TEST-0.0.3.

Not sure what is the best way to integrate it into the release workflow or if a universal binary is needed at all, I just download previously built macos binaries and use lipo to merge them with github actions.

@arbourd
Copy link
Author

arbourd commented Jan 21, 2022

@BurntSushi on the universal binary: #1737 (comment)

@arbourd
Copy link
Author

arbourd commented Oct 29, 2022

I was able to build both amd64/arm64 binaries and run the tests with cargo/cross on macOS 13 with an arm64 machine @BurntSushi

We might be good to go here if the tests pass 🤞🏻

@arbourd
Copy link
Author

arbourd commented Nov 7, 2022

Hey @BurntSushi, I don't mean to bother you, but could you please approve the workflow so I can continue on this?

@arbourd
Copy link
Author

arbourd commented Nov 7, 2022

Thank you! So it's failing because it looks like the target aarch64-apple-darwinisn't present. I had this problem locally as well but I was able to solve it by resolving the rustup target. I'll look into this a bit more 👀

@arbourd
Copy link
Author

arbourd commented Nov 7, 2022

Seems like this is still blocked by Cross because of cross-rs/cross#558. We could also use M1 runners if GitHub ever releases them.

I'll finish this PR up if either of these things ever come to fruition.

@unixsurfer
Copy link

Does anyone when this will be merged? I would like to use the pre-build package .

@BurntSushi
Copy link
Owner

@unixsurfer Use brew?

Otherwise I don't schedule my free time. It happens when it happens and if it happens. See: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#release

@unixsurfer
Copy link

@unixsurfer Use brew?

Otherwise I don't schedule my free time. It happens when it happens and if it happens. See: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#release

On my working laptop I can't use brew. I need to package it, using autopkg, and the easiest way is to use a pre-built dmg.

BurntSushi pushed a commit that referenced this pull request Jul 9, 2023
This doesn't add a universal binary, but instead keeps x86-64 and arm
as distinct binaries.

Fixes #1737, Closes #2099
BurntSushi pushed a commit that referenced this pull request Jul 9, 2023
This doesn't add a universal binary, but instead keeps x86-64 and arm
as distinct binaries.

Fixes #1737, Closes #2099
BurntSushi pushed a commit that referenced this pull request Jul 9, 2023
This doesn't add a universal binary, but instead keeps x86-64 and arm
as distinct binaries.

Fixes #1737, Closes #2099
BurntSushi pushed a commit that referenced this pull request Jul 9, 2023
This doesn't add a universal binary, but instead keeps x86-64 and arm
as distinct binaries.

Fixes #1737, Closes #2099
BurntSushi pushed a commit that referenced this pull request Jul 9, 2023
This doesn't add a universal binary, but instead keeps x86-64 and arm
as distinct binaries.

Fixes #1737, Closes #2099
BurntSushi pushed a commit that referenced this pull request Jul 9, 2023
This doesn't add a universal binary, but instead keeps x86-64 and arm
as distinct binaries.

Fixes #1737, Closes #2099
@BurntSushi
Copy link
Owner

BurntSushi commented Jul 9, 2023

I looked into this, and the fundamental problem here is that I do not know how to run tests for the aarch64-apple-darwin target in CI. It is possible to produce a binary, but I'm not comfortable doing that without also being able to run tests. (This PR also doesn't work at all as-is because you can't use Cross to build macOS targets. You never could do that and I don't see how that would ever work. You'd need a macOS Docker image, which I'm not sure even exists. And Cross doesn't support it.)

So this looks blocked on GitHub providing macOS arm CI runners. I'm therefore going to close this out for now.

@BurntSushi BurntSushi closed this Jul 9, 2023
@arbourd arbourd deleted the arm64-macos branch July 11, 2023 14:24
@bc-geoffl
Copy link

bc-geoffl commented Oct 6, 2023

what's the latest and greatest way to install ripgrep on apple silicon without homebrew?

Is ripgrep-13.0.0-arm-unknown-linux-gnueabihf.tar.gz the correct binary from releases?

@BurntSushi
Copy link
Owner

@bc-geoffl No, that isn't correct. Look at its name... It has "linux" in it, so it can't be for macOS.

I'm not a macOS user, but if you want to do it without Homebrew, you can install Rust and then build ripgrep from source.

@tekumara
Copy link

tekumara commented Oct 6, 2023

FYI m1 arm runners are now available https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/

@BurntSushi
Copy link
Owner

@tekumara Wow, about time! I had not seen that. I'll try it out and if it works, I'll get binaries available for the ripgrep 14 release.

@tekumara
Copy link

tekumara commented Oct 6, 2023

One gotcha I've just discovered is that the m1 runners are large and not standard sized runners, and so aren't free for open-source projects, and require a billing plan:

Larger runners are only available for organizations and enterprises using the GitHub Team or GitHub Enterprise Cloud plans.
Larger runners are only billed at the per-minute rate for the amount of time workflows are executed on them. There is no cost associated with creating a larger runner that is not being used by a workflow.

@BurntSushi
Copy link
Owner

Sigh.

I do personally have an M2 mac mini now, so I can worst case scenario upload a binary like I do for the Debian package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ship binaries that work on macOS arm targets
7 participants