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

strip = "symbols" doesn't work when cross-compiling from linux to macOS #114411

Open
roblabla opened this issue Aug 3, 2023 · 2 comments
Open
Labels
A-cross Area: Cross compilation A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@roblabla
Copy link
Contributor

roblabla commented Aug 3, 2023

Currently, when compiling for macOS with -C strip=symbols, rustc will try to invoke strip on the output binary to remove its symbols. This, unfortunately, fails when cross-compiling from linux, as the strip binary on linux only understands ELF files and will choke on the mach-o. This results in the following warnings in the build logs, and an unstripped binary output:

warning: stripping debug info with `strip` failed: exit status: 1
  |
  = note: /usr/bin/strip: /home/roblabla/repro/target/x86_64-apple-darwin/release/deps/repro-19371802bd981e48: file format not recognized

Ideally, rustc should either:

  1. Use a cross-target stripper, such as llvm-strip (which is currently packaged in rustup as part of llvm-tools-preview, CC Tracking Issue for llvm-tools-preview #85658)
  2. Allow the user to configure which strip utility it will use (which could then end up in .cargo/config) to use one provided by osxcross or llvm.

Reproduction steps:

cargo new testing
cd testing
curl -L https://github.com/roblabla/MacOSX-SDKs/releases/download/13.3/MacOSX13.3.sdk.tar.xz | tar xJ
echo '[profile.release]' >> Cargo.toml
echo 'strip = "symbols"' >> Cargo.toml
SDKROOT=$PWD/MacOSX13.3.sdk CARGO_TARGET_X86_64_APPLE_DARWIN_LINKER=rust-lld cargo build --target=x86_64-apple-darwin --release

Meta

rustc --version --verbose:

rustc 1.71.0 (8ede3aae2 2023-07-12)
binary: rustc
commit-hash: 8ede3aae28fe6e4d52b38157d7bfe0d3bceef225
commit-date: 2023-07-12
host: aarch64-apple-darwin
release: 1.71.0
LLVM version: 16.0.5
@roblabla roblabla added the C-bug Category: This is a bug. label Aug 3, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Aug 3, 2023
@Noratrieb Noratrieb added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-linkage Area: linking into static, shared libraries and binaries and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Aug 3, 2023
@roblabla
Copy link
Contributor Author

A coworker hit a weird case where Linux' strip would actually break the Mach-O instead of bailing out, rendering it inoperable (dyld would choke trying to load it, claiming /usr/lib/libobjc.A.dylib could not be found - which is obviously suspicious, as that lib is there on all darwin installs).

We finally tracked it down to this after a lot of trial and error, but this created a lot of confusion.

taiki-e referenced this issue in nextest-rs/nextest Mar 28, 2024
Restore behavior changed in 4e259a7, because
it turns out that `strip = "debuginfo"` still strips too much.

This was observed with the cargo-nextest 0.9.68-rc.1 binary on illumos, where
`pstack` showed lots of ??? marks.

Part of #1345.
@madsmtm
Copy link
Contributor

madsmtm commented Nov 12, 2024

@rustbot label A-cross O-macos

@rustbot rustbot added A-cross Area: Cross compilation O-macos Operating system: macOS labels Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cross Area: Cross compilation A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants