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

ship binaries that work on macOS arm targets #1737

Closed
nico opened this issue Nov 21, 2020 · 15 comments
Closed

ship binaries that work on macOS arm targets #1737

nico opened this issue Nov 21, 2020 · 15 comments
Labels
enhancement An enhancement to the functionality of the software. help wanted Others are encouraged to work on this issue. rollup A PR that has been merged with many others in a rollup.

Comments

@nico
Copy link

nico commented Nov 21, 2020

It'd be nice if there was a prebuilt binary of rg that ran without Rosetta 2 on ARM Macs. There could either be a separate macOS-arm binary, or there could be a single universal binary that runs on both ISAs.

rust-lang/rust#73908 covers support for this in upstream rust. This feature request is probably blocked on that completing.

https://github.com/shepmaster/rust/blob/silicon/silicon/README.md has some notes on cross-compiling.

@shepmaster
Copy link
Contributor

FWIW, ripgrep compiles fine on these machines, so that shouldn't be a problem.

% file $(which rg)
~/.cargo/bin/rg: Mach-O 64-bit executable arm64

@BurntSushi BurntSushi added the enhancement An enhancement to the functionality of the software. label Nov 23, 2020
@BurntSushi
Copy link
Owner

Thanks for the feature request. But there are some things I don't understand. Please consider that when filing feature requests, that not every uses macOS. So it would help to provide more details. Some questions I have for example:

  • I have no idea what it means to "run without Rosetta 2." Probably because I don't know what Rosetta 2 is. But even if I did, I don't know what it means to produce a binary without it.
  • I don't know what you mean by a "universal binary" in the feature title. Universal in what sense?

Either way, I don't see myself spending time on this any time soon. If someone else wanted to work on this, then my requirements are probably the following:

  1. It should work with Rust stable. I'm open to something that only works with Rust nightly, but it should be using something that is on track to be stabilized and is unlikely to see major changes.
  2. It should work with cross. @shepmaster's instructions look great, but I'd really prefer that it work like other binaries that are produced via cross compiling.
  3. And finally, that it can be done automatically via GitHub Actions.

If these requirements aren't met, then I'd probably say that Rust and macOS arm aren't ready yet. The main thing I want to avoid is adding CI for a binary that breaks frequently.

@BurntSushi BurntSushi added the help wanted Others are encouraged to work on this issue. label Nov 23, 2020
@atouchet
Copy link
Contributor

@BurntSushi

Rosetta 2 is a x86-64 to ARM64 translator. See: https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment

Running without Rosetta 2 means running as a native ARM64 application.

Universal binary is Apple's name for fat binaries which include binaries for multiple instruction sets. See: https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary

Universal binary in this sense means that it's packaged with both x86-64 and ARM64 binaries.

@BurntSushi
Copy link
Owner

OK, thanks, that helps clarify things. Unless producing a universal binary with the Rust toolchain is easy, I'd expect to host two binaries: one for x86_64 and one for arm. Just like we do for other platforms.

@shepmaster
Copy link
Contributor

  • It should work with Rust stable.

Not yet. In 6 weeks, perhaps, but right now you need beta.

  • It should work with cross. @shepmaster's instructions look great, but I'd really prefer that it work like other binaries that are produced via cross compiling.

Perhaps this comment should start some effort in the cross repo. This works today outside of cross, however:

% rustup component add rust-std --toolchain beta --target=aarch64-apple-darwin

% SDKROOT=$(xcrun -sdk macosx11.0 --show-sdk-path) \
MACOSX_DEPLOYMENT_TARGET=$(xcrun -sdk macosx11.0 --show-sdk-platform-version) \
cargo +beta build --target=aarch64-apple-darwin

    Finished dev [unoptimized + debuginfo] target(s) in 29.32s

% file target/aarch64-apple-darwin/debug/rg
target/aarch64-apple-darwin/debug/rg: Mach-O 64-bit executable arm64
  • And finally, that it can be done automatically via GitHub Actions.

This should be achievable.

Unless producing a universal binary with the Rust toolchain is easy

Depends what "with the Rust toolchain" entails. After doing the above build...

% cargo +beta build --target=x86_64-apple-darwin

% lipo -create -output rg target/{aarch64,x86_64}-apple-darwin/debug/rg

% file rg
rg: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
rg (for architecture x86_64):	Mach-O 64-bit executable x86_64
rg (for architecture arm64):	Mach-O 64-bit executable arm64

@BurntSushi
Copy link
Owner

That looks great! I'd be happy adopting all of that at any time. Looks simple enough, and it being in beta would be fine with me.

@BurntSushi
Copy link
Owner

@shepmaster Thank you for answering my questions with great detail. :-)

SimplyDanny added a commit to SimplyDanny/sd that referenced this issue Mar 19, 2021
This target requires cross-compilation on the default (x86_64) `macos-latest`
platform. However, `cross` does [not yet](cross-rs/cross#508)
provide the right target. If tests can be skipped a build solution outside
of `cross` is already discussed [here](BurntSushi/ripgrep#1737).
SimplyDanny added a commit to SimplyDanny/sd that referenced this issue Mar 19, 2021
This target requires cross-compilation on the default (x86_64) `macos-latest`
platform. However, `cross` does [not yet](cross-rs/cross#508)
provide the right target. If tests can be skipped a build solution outside
of `cross` is already discussed [here](BurntSushi/ripgrep#1737).
SimplyDanny added a commit to SimplyDanny/sd that referenced this issue Mar 19, 2021
This target requires cross-compilation on the default (x86_64) `macos-latest`
platform. However, `cross` does [not yet](cross-rs/cross#508)
provide the right target. If tests can be skipped a build solution outside
of `cross` is already discussed [here](BurntSushi/ripgrep#1737).
BurntSushi pushed a commit that referenced this issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 BurntSushi changed the title Make macOS prebuilt binary universal ship binaries that work on macOS arm targets Jul 9, 2023
@BurntSushi
Copy link
Owner

I'm not too keen on doing a universal binary here. It seems wasteful? I'd rather just build separate binaries for x86-64 and arm targets like I do for everything else.

It looks like it is possible to build an arm binary by just doing rustup target add aarch64-apple-darwin and then cargo build --release --target aarch64-apple-darwin on a macOS x86-64 host. However, there is no way to run tests and I'd really rather I only ship binaries that I can actually test.

So for now, I'd consider this blocked on GitHub providing macOS arm runners in CI.

@vadz
Copy link

vadz commented Jul 9, 2023

FWIW https://www.macstadium.com/ provides free access to ARM Macs for open source projects and we used it to set up GitHub self-hosted runner there -- and this seems to work pretty well.

Sorry if this looks like advertisement, I'm not affiliated with MacStadium in any way, I'm just grateful to them for allowing us to build and test under ARM and thought this could be useful for this project too.

@BurntSushi
Copy link
Owner

Thanks. Unless it's super easy to do, I'm not inclined to do anything self-hosted here.

@claviola
Copy link

claviola commented Jul 11, 2023

FWIW https://www.macstadium.com/ provides free access to ARM Macs for open source projects and we used it to set up GitHub self-hosted runner there -- and this seems to work pretty well.

Doesn't look like they do anymore. I came across https://www.macstadium.com/opensource, but it 404s - last in the Internet Archive on March of this year: http://web.archive.org/web/20230319190128/https://www.macstadium.com/opensource-application

edit: FWIW this seems to work quite well: https://github.com/joseluisq/rust-linux-darwin-builder
the only downside is that the image is rather large.

@larkost
Copy link

larkost commented Nov 2, 2023

@BurntSushi
Copy link
Owner

@larkost That blog doesn't make it clear, but I believe you need to pay for it.

@BurntSushi
Copy link
Owner

BurntSushi commented Nov 25, 2023

My plan is to do this manually on my M2 mac mini until GitHub provides free runners: https://github.com/BurntSushi/ripgrep/blob/a2907db2de20fd33b0bf02d9bd1375da06218865/ci/build-and-publish-m2

@BurntSushi BurntSushi added the rollup A PR that has been merged with many others in a rollup. label Nov 25, 2023
BurntSushi added a commit that referenced this issue Nov 25, 2023
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Nov 28, 2023
14.0.2 (2023-11-27)
===================
This is a patch release with a few small bug fixes.

Bug fixes:

* [BUG #2654](BurntSushi/ripgrep#2654):
  Fix `deb` release sha256 sum file.
* [BUG #2658](BurntSushi/ripgrep#2658):
  Fix partial regression in the behavior of `--null-data --line-regexp`.
* [BUG #2659](BurntSushi/ripgrep#2659):
  Fix Fish shell completions.
* [BUG #2662](BurntSushi/ripgrep#2662):
  Fix typo in documentation for `-i/--ignore-case`.


14.0.1 (2023-11-26)
===================
This a patch release meant to fix `cargo install ripgrep` on Windows.

Bug fixes:

* [BUG #2653](BurntSushi/ripgrep#2653):
  Include `pkg/windows/Manifest.xml` in crate package.


14.0.0 (2023-11-26)
===================
ripgrep 14 is a new major version release of ripgrep that has some new
features, performance improvements and a lot of bug fixes.

The headlining feature in this release is hyperlink support. In this release,
they are an opt-in feature but may change to an opt-out feature in the future.
To enable them, try passing `--hyperlink-format default`. If you use [VS Code],
then try passing `--hyperlink-format vscode`. Please [report your experience
with hyperlinks][report-hyperlinks], positive or negative.

[VS Code]: https://code.visualstudio.com/
[report-hyperlinks]: BurntSushi/ripgrep#2611

Another headlining development in this release is that it contains a rewrite
of its regex engine. You generally shouldn't notice any changes, except for
some searches may get faster. You can read more about the [regex engine rewrite
on my blog][regex-internals]. Please [report your performance improvements or
regressions that you notice][report-perf].

[report-perf]: BurntSushi/ripgrep#2652

Finally, ripgrep switched the library it uses for argument parsing. Users
should not notice a difference in most cases (error messages have changed
somewhat), but flag overrides should generally be more consistent. For example,
things like `--no-ignore --ignore-vcs` work as one would expect (disables all
filtering related to ignore rules except for rules found in version control
systems such as `git`).

[regex-internals]: https://blog.burntsushi.net/regex-internals/

**BREAKING CHANGES**:

* `rg -C1 -A2` used to be equivalent to `rg -A2`, but now it is equivalent to
  `rg -B1 -A2`. That is, `-A` and `-B` no longer completely override `-C`.
  Instead, they only partially override `-C`.

Build process changes:

* ripgrep's shell completions and man page are now created by running ripgrep
with a new `--generate` flag. For example, `rg --generate man` will write a
man page in `roff` format on stdout. The release archives have not changed.
* The optional build dependency on `asciidoc` or `asciidoctor` has been
dropped. Previously, it was used to produce ripgrep's man page. ripgrep now
owns this process itself by writing `roff` directly.

Performance improvements:

* [PERF #1746](BurntSushi/ripgrep#1746):
  Make some cases with inner literals faster.
* [PERF #1760](BurntSushi/ripgrep#1760):
  Make most searches with `\b` look-arounds (among others) much faster.
* [PERF #2591](BurntSushi/ripgrep#2591):
  Parallel directory traversal now uses work stealing for faster searches.
* [PERF #2642](BurntSushi/ripgrep#2642):
  Parallel directory traversal has some contention reduced.

Feature enhancements:

* Added or improved file type filtering for Ada, DITA, Elixir, Fuchsia, Gentoo,
  Gradle, GraphQL, Markdown, Prolog, Raku, TypeScript, USD, V
* [FEATURE #665](BurntSushi/ripgrep#665):
  Add a new `--hyperlink-format` flag that turns file paths into hyperlinks.
* [FEATURE #1709](BurntSushi/ripgrep#1709):
  Improve documentation of ripgrep's behavior when stdout is a tty.
* [FEATURE #1737](BurntSushi/ripgrep#1737):
  Provide binaries for Apple silicon.
* [FEATURE #1790](BurntSushi/ripgrep#1790):
  Add new `--stop-on-nonmatch` flag.
* [FEATURE #1814](BurntSushi/ripgrep#1814):
  Flags are now categorized in `-h/--help` output and ripgrep's man page.
* [FEATURE #1838](BurntSushi/ripgrep#1838):
  An error is shown when searching for NUL bytes with binary detection enabled.
* [FEATURE #2195](BurntSushi/ripgrep#2195):
  When `extra-verbose` mode is enabled in zsh, show extra file type info.
* [FEATURE #2298](BurntSushi/ripgrep#2298):
  Add instructions for installing ripgrep using `cargo binstall`.
* [FEATURE #2409](BurntSushi/ripgrep#2409):
  Added installation instructions for `winget`.
* [FEATURE #2425](BurntSushi/ripgrep#2425):
  Shell completions (and man page) can be created via `rg --generate`.
* [FEATURE #2524](BurntSushi/ripgrep#2524):
  The `--debug` flag now indicates whether stdin or `./` is being searched.
* [FEATURE #2643](BurntSushi/ripgrep#2643):
  Make `-d` a short flag for `--max-depth`.
* [FEATURE #2645](BurntSushi/ripgrep#2645):
  The `--version` output will now also contain PCRE2 availability information.

Bug fixes:

* [BUG #884](BurntSushi/ripgrep#884):
  Don't error when `-v/--invert-match` is used multiple times.
* [BUG #1275](BurntSushi/ripgrep#1275):
  Fix bug with `\b` assertion in the regex engine.
* [BUG #1376](BurntSushi/ripgrep#1376):
  Using `--no-ignore --ignore-vcs` now works as one would expect.
* [BUG #1622](BurntSushi/ripgrep#1622):
  Add note about error messages to `-z/--search-zip` documentation.
* [BUG #1648](BurntSushi/ripgrep#1648):
  Fix bug where sometimes short flags with values, e.g., `-M 900`, would fail.
* [BUG #1701](BurntSushi/ripgrep#1701):
  Fix bug where some flags could not be repeated.
* [BUG #1757](BurntSushi/ripgrep#1757):
  Fix bug when searching a sub-directory didn't have ignores applied correctly.
* [BUG #1891](BurntSushi/ripgrep#1891):
  Fix bug when using `-w` with a regex that can match the empty string.
* [BUG #1911](BurntSushi/ripgrep#1911):
  Disable mmap searching in all non-64-bit environments.
* [BUG #1966](BurntSushi/ripgrep#1966):
  Fix bug where ripgrep can panic when printing to stderr.
* [BUG #2046](BurntSushi/ripgrep#2046):
  Clarify that `--pre` can accept any kind of path in the documentation.
* [BUG #2108](BurntSushi/ripgrep#2108):
  Improve docs for `-r/--replace` syntax.
* [BUG #2198](BurntSushi/ripgrep#2198):
  Fix bug where `--no-ignore-dot` would not ignore `.rgignore`.
* [BUG #2201](BurntSushi/ripgrep#2201):
  Improve docs for `-r/--replace` flag.
* [BUG #2288](BurntSushi/ripgrep#2288):
  `-A` and `-B` now only each partially override `-C`.
* [BUG #2236](BurntSushi/ripgrep#2236):
  Fix gitignore parsing bug where a trailing `\/` resulted in an error.
* [BUG #2243](BurntSushi/ripgrep#2243):
  Fix `--sort` flag for values other than `path`.
* [BUG #2246](BurntSushi/ripgrep#2246):
  Add note in `--debug` logs when binary files are ignored.
* [BUG #2337](BurntSushi/ripgrep#2337):
  Improve docs to mention that `--stats` is always implied by `--json`.
* [BUG #2381](BurntSushi/ripgrep#2381):
  Make `-p/--pretty` override flags like `--no-line-number`.
* [BUG #2392](BurntSushi/ripgrep#2392):
  Improve global git config parsing of the `excludesFile` field.
* [BUG #2418](BurntSushi/ripgrep#2418):
  Clarify sorting semantics of `--sort=path`.
* [BUG #2458](BurntSushi/ripgrep#2458):
  Make `--trim` run before `-M/--max-columns` takes effect.
* [BUG #2479](BurntSushi/ripgrep#2479):
  Add documentation about `.ignore`/`.rgignore` files in parent directories.
* [BUG #2480](BurntSushi/ripgrep#2480):
  Fix bug when using inline regex flags with `-e/--regexp`.
* [BUG #2505](BurntSushi/ripgrep#2505):
  Improve docs for `--vimgrep` by mentioning footguns and some work-arounds.
* [BUG #2519](BurntSushi/ripgrep#2519):
  Fix incorrect default value in documentation for `--field-match-separator`.
* [BUG #2523](BurntSushi/ripgrep#2523):
  Make executable searching take `.com` into account on Windows.
* [BUG #2574](BurntSushi/ripgrep#2574):
  Fix bug in `-w/--word-regexp` that would result in incorrect match offsets.
* [BUG #2623](BurntSushi/ripgrep#2623):
  Fix a number of bugs with the `-w/--word-regexp` flag.
* [BUG #2636](BurntSushi/ripgrep#2636):
  Strip release binaries for macOS.
@tekumara
Copy link

tekumara commented Feb 4, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement to the functionality of the software. help wanted Others are encouraged to work on this issue. rollup A PR that has been merged with many others in a rollup.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants