-
Notifications
You must be signed in to change notification settings - Fork 0
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
Rustup can be invoked by this module as the wrong architecture on MacOS #80
Comments
It’s been a while since I worked on this, so I could have the details wrong. Also, I don’t have an ARM Mac to test this on, which makes it harder to track down the issue myself. I think the issue is the What does |
Probably the best way to solve the |
Thanks for the replies!
I'd expect that too! But it does not seem to be occurring; it seems like if anything up the chain has been invoked as x86, even without an explicit
When When
I don't think that'll change anything, sadly. I think that, so long as Bolt's x86-only (which it is for now), regardless of how
I'll take a stab at a PR (my Ruby is rusty though) in the coming weeks and you can decide if the |
That sounds like a bug in this module or maybe in
Similarly, if I install the
I figure that the architecture of It still might be a problem later once the toolchains binaries get fixed. All that said, it does seem to be working on my machine (not really a surprise, I suppose). Can you run it with the environment variable For example, on my local machine:
|
My output looks exactly like yours when I run If I install it via
This is easier to reproduce without Puppet entirely. If I
If I run
But if I run it via this module in an x86 |
The linked PR does seem to work, and always installs the requisite base/bootstrap toolchain as the native architecture. |
Great, thanks! Merged, with only a bit of struggling with CI. I imagine that fixes the problem with the wrappers being the wrong arch, but I would not have expected this to fix the issue where ~/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/* are x86_64 instead of ARM. Can you confirm that? |
Sorry, I could have been clearer in the earlier comment: the issue was only ever with |
Ah, okay. That makes a lot more sense. |
I’ve just cut a release that includes this. Do you think anything else needs to be done before closing this? Thanks again for report and the PR! |
Just tested the new release, and my test succeeded on my laptop, but failed on a blank MacOS VM. That's entirely my fault. My The fix is simple and will be linked right after this comment; upcase the "d" in "Darwin". So sorry, I should have tested on a fresh install before I sent that in and made you spend the time. Please don't feel pressured to cut a second release any time soon; this is a fairly rare issue and I'm happy to pin to master until whenever's convenient for you. |
Ha ha, no problem. I should have caught that in review. |
Tested on |
Ok, I cut a new release with an additional fix for macOS (in |
Context/Setup
brew install --cask puppetlabs/puppet/puppet-bolt
, the suggested install method.arm64
, and only provides anx86_64
installer:https://downloads.puppet.com/mac/puppet-tools/12/x86_64/puppet-bolt-3.27.4-1.osx12.dmg
at the time of this writing. This means thatbolt
will run via Rosetta in x86 emulation mode.rustup self uninstall
followed byrm -rf ~/.rustup ~/.cargo
should reset things to this state, albeit somewhat destructively).To reproduce
$USER
):file $(which cargo)
.Expected behavior:
cargo
andrustc
report file types matching the host architecture. For an ARM mac that would look likeObserved behavior
Why this matters
So what happens if
cargo
is a non-native architecture?cargo
's build behavior. It andrustc
will still compile/cross-compile Rust code normally according to the targets configured inrustup
and will produce binaries of the selected architecture.cargo
andrustc
will run unusually slowly on MacOS due to the presence of binary emulation translating the x86_64 binaries into arm64 code.cargo
and their subprograms will prefer to launch x86 programs on MacOS. In other words, ifcargo run
or some Cargo plugin runs a universal binary on the system (like, saysudo
), that subprogram will run in x86 mode. Even if spawned subprograms do not support x86 execution (in which case cargo will spawn them as arm64), those programs' spawned subprocesses will still run preferring x86 execution.That last one can cause problems. I encountered one such issue where the
cargo flamegraph
plugin supplied byflamegraph-rs
runs its innerdtrace
process as x86, causingdtrace
to fail when it traced arm64 processes. The bug report for that issue is here, and I blogged about the discovery process of this issue here.Given that rustup/
cargo
installations can persist untouched for long periods of time, and given that the main compiler suite still works, I think it's likely that incorrect-architecture installations of cargo/rustc by this module persist without users' knowledge in many cases, silently causing slowdowns and occasionally causing louder issues like the above.Suggested resolution
When this module bootstraps
cargo
with therustup
resource, or when it installs a per-toolchaincargo
via therustup::toolchain
resource, it should allow user specification of the architecture to those resources.The new
architecture =>
ortoolchain_architecture =>
parameter that users can specify should, if unspecified, default to the invoking machine's native architecture via the "architecture" fact.When this module invokes subprograms internally, they should be wrapped in the arch command to force the architecture as requested by the user.
This behavior need only be present on MacOS, as other platforms do not do multiarch/binfmt translation in the same way (and the issue is much more common on MacOS than on free operating systems due to the frequently limited availability of source builds, as is the case with
puppet-bolt
in this case: only an x86_64 binary installable is provided, and build steps for creating a correct executable are not readily available).The text was updated successfully, but these errors were encountered: