-
-
Notifications
You must be signed in to change notification settings - Fork 50
SIGKILL for Rust projects with build.rs on M1 Macs #85
Comments
does it work for C/C++ invocations for you? are you using the latest version of zld? |
C/C++ as in, clang with -fuse-ld |
Yes, I'm using the latest version. This is the result of
I'll try it out with C/C++ and report back. |
Following up: A simple 'hello world' works for both C and C++ with In addition Rust programs that do not use |
gotcha. can you write out a full example of how to trigger this crash here? (unfortunately, i don't own an M1 mac, but maybe i can wrangle someone in to helping, or use an instance in the cloud) |
@michaeleisel Here's a repository with the minimum needed to demonstrate the crash: https://github.com/kettle11/rust_zld_crash I'd help more here, but I haven't dived into what's causing the issue. There's always a chance it's somehow local to my machine, but based on that comment I linked earlier I think that's not the case. Let me know if you need me to test anything! |
I wonder if it's the misaligned reads in
and see if it works. just a longshot if you want to try it |
I tried this, but get the same behavior: michaelkirk@a68631f
edit: for completeness, I get the same error on the POC app posted above:
|
|
Ok, maybe more interesting, it appears to be an issue with code signing: (from Console.app)
|
nice, yeah code signing validation fails with |
Let me know if you'd like me to try anything. |
there appears to be a bug due to some interaction between the file system and codesigning validation. for instance, doing |
Thanks for looking into it @michaeleisel. Using the I didn't do very thorough testing, but there appeared to be no (or only very small) speedups in incremental build times while using zld. Honestly, I was hoping it'd be a bit more. Do you expect the changes you made to work around the code signing issue might have significantly degraded performance?
|
no, that change has little perf effect (in fact, it actually sped it up by ~3% for me). but if you can provide me a way of doing the linking myself, i can investigate |
@michaelkirk It is possible that the vast majority of the time is spent inside rustc and not the linker. If you are on nightly you can try |
Thanks for the debugging instructions @bjorn3. It seems it's probably a separate issue, so I can follow up with a new issue after investigation. I'm away for a bit, but will investigate further in ~3 days. Thanks again for working around the code signing issue @michaeleisel. |
Just wanted to note that apparently on MacOS 12.0.1 on M1 and M1Pro (so probably it's not about the chipset), code signing seems to be incorrect or no signature was found the second time the build result changes. The reason I had to resort to an alternative linker in the first place was link failures with the system linker in any of my projects that pulled in curl-sys. Now I am resorting to a nix-pkg provided linker by adjusting cargo's configuration like so
Which then launches a nix shell with all kinds of useful dependencies made available, which apparently also causes a different linker to be used. #! /usr/bin/env nix-shell
#! nix-shell -i bash -p pkg-config openssl libiconv darwin.apple_sdk.frameworks.Security darwin.apple_sdk.frameworks.SystemConfiguration darwin.apple_sdk.frameworks.Foundation darwin.apple_sdk.frameworks.AppKit curl libgpgerror gpgme
$@ This adds 500ms to each rustc invocation at the very least but works for now. Maybe others find this place with similar experiences so we can figure out an actual solution. |
It's probably using the default linker, |
I think I do, here is my configuration for ZLD overrides, using the latest downloadable x86 version. [target.aarch64-apple-darwin]
rustflags = ["-C", "link-arg=-fuse-ld=/usr/local/bin/zld"] Then this should work to reproduce, unfortunately it involves manual steps: # on MacOS 12.0.1 with latest XCode, might be important if there is a chance the system linker is at fault.
# It might very well be because it's downright broken and I basically can't link most Rust projects with it anymore.
git clone https://github.com/rust-lang/cargo
cd cargo
cargo test
# the above works
# now edit a test file like required_features.rs by adding a newline in a test or modifying it slighly.
cargo test
Running tests/testsuite/main.rs (target/debug/deps/testsuite-e43ded086d2ec039)
error: test failed, to rerun pass '--test testsuite'
Caused by:
process didn't exit successfully: `/Users/byron/dev/github.com/rust-lang/cargo/target/debug/deps/testsuite-e43ded086d2ec039` (signal: 9, SIGKILL: kill) It might not happen after the first edit, I needed two. Here is what the system log has to say about that:
It could probably reproduce in other projects as well, but this one definitely shows the issue. Thanks a lot for taking a look, I will be happy to help with testing as much as I can. Unfortunately I am unable to build zld myself on ARM64. |
I can confirm I have a SIGKILL issue when running buildscripts on Mac and it's enough for me to disable zld to make this issue go away. Some diagnostics info:
Sample project I've used: any project with
Then, if I have zld enabled, the compilation fails:
When I disable it and restart the shell, it works:
|
@Byron @SomeoneToIgnore could this be due to gatekeeper? When you run |
I suspect it could be, but alas have no idea how to verify it exactly. Running the binary directly seem to work:
|
@SomeoneToIgnore are you on the latest release, 1.3.3? |
Oh, that's a good catch, brew package seems to be outdated:
So, I guess somebody has to update it in their repo? |
Had tried the binary from the releases page and it seems to work (I had to force it to be opened for the first time, as with any other software downloaded from the internet on modern macs). |
Thanks for looking into this. I was using the latest version from the releases page,
To be sure, I just tried again and after a first successful build, the next one caused invalid binaries to be created.
To me, nothing changed, unfortunately. I will keep trying as an update of the Xcode command-line utilities is coming in, maybe that changes something. |
Just to recap:
So have to go back to the only fix that worked for me, a nix wrapper which unfortunately slows down every command invocation by at least 0.5s. |
I'm still seeing the SIGKILL caused by an invalid code signature in zld 1.3.3 installed from Homebrew on an M1 Mac. It seems to be pretty reproducible using https://github.com/LukeMathWalker/zero-to-production/tree/7ed962996b5defb74c7b37d58c9a2d9d8591ccb2, although for a Homebrew-installed version of zld you need to fix the path in |
I'm also getting a SIGKILL for a package w/ a build.rs (in my case, serde-derive) on version 1.3.3 installed by Homebrew. M1 Max MacBook Pro, macOS 12.2.1. Error snippet below:
I've read through the thread and don't have any ideas yet. Tried and failed to dtrace it before finding the thread. |
could people try doing next, if that doesn't work, could people show me the result of |
Yeah, here was the result:
Not sure what binary you mean here, I can't check the code-signing of the resultant binary if it doesn't build with zld. Here's zld though:
Here's the codesign output for a binary built without zld:
|
With zld
With ld
|
So @Byron to your point, if ld64 fails for something, as you say with the assertion failure, it's not a priority to support for zld @JammyStuff that project seems cumbersome to build, requiring a running postgresql server and docker for the build step itself. To be honest, that seems like a rare and undesirable way of building things, and I'm less concerned about supporting it. Do you have a more orthodox example? @bitemyapp I made a test project with Is everyone using zld 1.3.3 (e.g., from the release page)? Does anyone have a project that can reliably reproduce this? And can people help me understand how much this is affecting their workflow, so I know how to prioritize it? |
@n8henrie has provided me in #110 with an excellent reproducible example, and i have merged a fix to master that works for me. basically there's a bug somewhere in the filesystem or in the codesigning validation, and we have to keep trying different ways of jiggling around the output file until apple likes it. in this case, i tried using |
built version: zld.zip |
Seems to be working great. No longer crashing in the Two workarounds:
$ cd ~/.local/bin
$ unzip ~/Downloads/zld.zip -d .
$ ./zld # note that you get a warning popup if you try to execute
$ xattr -l ./zld # note the quarantine flag
com.apple.quarantine: 0081;6272a68e;Firefox;F529D2ED-995E-4369-B9BA-8E84F261D88E
$ xattr -d com.apple.quarantine ./zld
$ ./zld # now runs without issue
ld: warning: platform not specified
ld: warning: -arch not specified
ld: warning: No platform min-version specified on command line
ld: no object files specified To undo the codesigning "approval" (if you ever wish to do so) $ spctl --list | grep zld # note the exception is there
$ spctl --remove ~/.local/bin/zld |
Released in 1.3.4 |
I'd love to help releasing that to homebrew, but not sure where does |
I was trying to use
zld
on an M1 Mac for those sweet link time improvements, but I'm running into this crash while building:It seems any crate with a build.rs file hits this while building.
@benmkw mentioned this issue as well: #73 (comment)
Unfortunately this makes zld unusable for most projects with Rust / M1 Macs.
The text was updated successfully, but these errors were encountered: