https://sourceware.org/bugzilla/show_bug.cgi?id=31972
Bug ID: 31972
Summary: strip cause SIGKILL in macOS
Product: binutils
Version: 2.42
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: lapla.cogito at gmail dot com
Target Milestone: ---
I would like to report a problem with using strip on macOS (M1 MAX, but I
believe this problem also occurs on x86_64).
I ran into this problem while writing code in Rust. Therefore, I will show you
a procedure that allows you to reproduce a similar event:
````
$ cargo new foo && cd foo
$ cargo run --release
```
This produces the following output:
```
Compiling foo v0.1.0 (/path_to_binary)
Finished `release` profile [optimized] target(s) in 0.72s
Running `target/release/foo`.
zsh: killed cargo run --release
```
Noting that simply `cargo build` runs fine, I thought strip might be the cause.
Then I realized that the output changes when I use build scripts in Rust:
```
$ cat << EOF > build.rs
fn main() {
println!("cargo::rerun-if-changed=src/main.rs");
}
EOF
```
After creating build.rs, `cargo run --release` would result in the following
output:
```
error: failed to run custom build command for `foo v0.1.0 (/path_to_binary)`
Caused by:
process didn't exit successfully: `/path_to_build_script/build-script-build`
(signal: 9, SIGKILL: kill)
```
Both cases (with and without build.rs) don't occur if the standard macOS binary
(/usr/bin/strip) is used as strip instead of binutils from Homebrew. For this
reason, I suspect that this is a bug in the binutils strip.
Moreover, from looking at the source code, it appears that the binutils strip
is not Mach-O Version 2 compliant, and I believe the two problems mentioned
above are most likely caused by this.
I see two main ways to deal with this problem:
- Reject Mach-O Version 2 when it is given
- Modify the strip to work correctly even if Mach-O Version 2 is given
--
You are receiving this mail because:
You are on the CC list for the bug.
