unable to find Static system library 'gcc_eh'

[serjflint]

Zig Version

0.11.0

Steps to Reproduce and Observed Behavior

Hi! I am trying to statically cross-compile Ruff from Linux to Linux-ARM (aarch64-unknown-linux-gnu). At the linking stage with command

TARGET=aarch64-unknown-linux-gnu
PKG_CONFIG_ALLOW_CROSS=1 cargo zigbuild --release --target=$TARGET --verbose

I get an error

error: linking with `/home/sandbox/.cache/cargo-zigbuild/0.17.3/zigcc-aarch64-unknown-linux-gnu.sh` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/tmp/cargo/bin:/opt/zig:/usr/local/cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/Berkanavt/bin/scripts" VSLANG="1033" "/home/sandbox/.cache/cargo-zigbuild/0.17.3/zigcc-aarch64-unknown-linux-gnu.sh" "/tmp/rustcGyi8cX/symbols.o" "/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/ruff_python_formatter-d5103041bb61df09.ruff_python_formatter.28e285a93788288c-cgu.0.rcgu.o" "-Wl,--as-needed" "-L" "/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps" "-L" "/place/rust/contrib/ruff/target/release/deps" "-L" "/usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-lgcc_eh" "-lgcc" "-lc" "/usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-e98df64cadd875cc.rlib" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/ruff_python_formatter-d5103041bb61df09" "-Wl,--gc-sections" "-static" "-no-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-undefined" "dynamic_lookup"
  = note: error: unable to find Static system library 'gcc_eh' using strategy 'no_fallback'. searched paths:
            /place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libgcc_eh.a
            /place/rust/contrib/ruff/target/release/deps/libgcc_eh.a
            /usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgcc_eh.a
            /usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgcc_eh.a
          error: unable to find Static system library 'gcc' using strategy 'no_fallback'. searched paths:
            /place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libgcc.a
            /place/rust/contrib/ruff/target/release/deps/libgcc.a
            /usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgcc.a
            /usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgcc.a
          

error: could not compile `ruff_python_formatter` (bin "ruff_python_formatter") due to previous error

Caused by:
  process didn't exit successfully: `/usr/local/rustup/toolchains/1.72-x86_64-unknown-linux-gnu/bin/rustc --crate-name ruff_python_formatter --edition=2021 crates/ruff_python_formatter/src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto=fat -C codegen-units=1 --cfg 'feature="default"' --cfg 'feature="serde"' -C metadata=d5103041bb61df09 -C extra-filename=-d5103041bb61df09 --out-dir /place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps --target aarch64-unknown-linux-gnu -C linker=/home/sandbox/.cache/cargo-zigbuild/0.17.3/zigcc-aarch64-unknown-linux-gnu.sh -L dependency=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps -L dependency=/place/rust/contrib/ruff/target/release/deps --extern anyhow=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libanyhow-d773c4b449ba7692.rlib --extern bitflags=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libbitflags-00cbddb37865de95.rlib --extern clap=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libclap-c3150b07e1bd02d0.rlib --extern countme=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libcountme-66bb619c24c71fb6.rlib --extern itertools=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libitertools-1327eb584da2ff46.rlib --extern memchr=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libmemchr-570a1c555cf2c156.rlib --extern once_cell=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libonce_cell-44bf3c56b546124e.rlib --extern ruff_formatter=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_formatter-afac7d90f3117771.rlib --extern ruff_python_ast=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_python_ast-61130ac81486df61.rlib --extern ruff_python_formatter=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_python_formatter-bafd76a0a46edff9.rlib --extern ruff_python_index=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_python_index-edb6a4afaa5026cc.rlib --extern ruff_python_parser=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_python_parser-f2abe69db5e13fb4.rlib --extern ruff_python_trivia=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_python_trivia-022058b197ec5c90.rlib --extern ruff_source_file=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_source_file-f8b3fa83166c3783.rlib --extern ruff_text_size=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libruff_text_size-0568ea01c8d42034.rlib --extern rustc_hash=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/librustc_hash-27719bb5f9f9bf70.rlib --extern serde=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libserde-0f4933fdf04b23e6.rlib --extern smallvec=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libsmallvec-6f1193bc99ed01c8.rlib --extern static_assertions=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libstatic_assertions-0ce627262f703e27.rlib --extern thiserror=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libthiserror-0544a68f0c99f803.rlib --extern tracing=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libtracing-bb3516bdceedb125.rlib --extern unicode_width=/place/rust/contrib/ruff/target/aarch64-unknown-linux-gnu/release/deps/libunicode_width-c435dab1e04893bc.rlib -C target-feature=+crt-static -C` (exit status: 1)

I have config.toml like this:

[target.aarch64-unknown-linux-gnu]
linker = "clang"
rustflags = [
  "-C", "target-feature=+crt-static",
]

The maintainer of cargo-zigbuild advised me to open an issue here
rust-cross/cargo-zigbuild#186

Expected Behavior

Successful build as for Linux-x86_64

[polarathene]

You can reproduce this with a basic hello world program in Rust. That should simplify tracking down the cause.

While I haven't tried with Zig directly for an equivalent Hello World program, at a glance it looks like Zig supports static builds just fine. (EDIT: zig build vs zig cc is a different story it seems)

It's more likely to be an incompatibility with how cargo-zigbuild is implemented? libgcc / gcc_eh are related to internals with the rust compiler or cargo IIRC. Perhaps there is some logic there that needs to be carried over to cargo-zigbuild 🤷‍♂️

---

EDIT: I am partially wrong.

• While those files to link are related to the cargo build, Zig cannot compile a basic hello.c with static linking (the advice there doesn't seem to apply to libc.a as it'd compile but segfault when run on the same build host).
• Zig needs to fix their cc static build support before cargo-zigbuild can do anything about it.

[alexrp]

I'm pretty sure we can (and should) satisfy libgcc_eh by linking Zig's bundled libunwind, just as we do for libgcc_s.

[polarathene]

@alexrp while that will resolve the linking issue, AFAIK zig cc will still enforce dynamic linking for glibc and static linking for musl.

Anyone that lands here when this issue is closed will want to still only use musl for static builds.

---

Normally you would want to be wary of glibc static linking of course as there are known caveats, but for Rust there is eyra which hooks into the -gnu / glibc target for providing it's own libc ABI implementation without the static glibc caveats.

However even with the ability to opt-out of dynamic linking, I recall another issue with Zig was that it also forcibly linked it's own CRT? eyra would provide it's own IIRC (Building eyra without Zig still requires a linker flag-nostartfiles).

[alexrp]

Is this the only open issue we have tracking static glibc support? If so, the issue title is somewhat suboptimal...

[polarathene]

Is this the only open issue we have tracking static glibc support?

No, there's a few IIRC. At least this one for static glibc, and another for users that would like dynamic linking for musl (such distros have their cargo package build modified for example to patch the musl target to dynamic link by default instead).

[andrewrk]

I don't think it makes sense to support "static glibc" as an explicit feature, and such a use case is not motivating to me in the slightest. However if an argument can be made that the use case is not working due to bugs or other surprising behavior, then perhaps the use case can be made to work.

Zig is supposed to support linking against the object files and other build artifacts installed on one's system, so if that includes a static glibc, then it should be possible to do even without Zig having explicit support for it.

[polarathene]

I don't think it makes sense to support "static glibc" as an explicit feature, and such a use case is not motivating to me in the slightest.

I understand that, and don't really endorse static glibc either. However I think eyra is a valid use-case example which Zig is presently incompatible with.

Dynamic linking for musl is also a valid use-case, so having the ability to explicitly request static or dynamic linking would fix these build concerns.

Zig is supposed to support linking against the object files and other build artifacts installed on one's system, so if that includes a static glibc, then it should be possible to do even without Zig having explicit support for it.

I believe I tried to do that here, but due to the enforced dynamic linking flag, even though there are no libraries dynamically linked on the executable, it segfaults. I'd consider that a bug?

The other issue with compatibility with eyra also involves opt-out via linker flag -nostartfiles. Rust would provide those by default otherwise and Zig appears to attempt the same AFAIK (but additionally ignores this linker flag). I don't think there is an existing issue regarding this flag, but there are a few issues (all related to zig cc with Rust), this one in particular seems to be relevant (focused on musl with later comments suggesting workarounds that would not work for eyra).

[andrewrk]

I believe I tried to do that here, but due to the enforced dynamic linking flag, even though there are no libraries dynamically linked on the executable, it segfaults. I'd consider that a bug?

Yeah sure, I buy that argument.

My above comment is mainly in response to @alexrp.

[alexrp]

Just to be clear, I don't personally care about static glibc either, except to the extent that we're handling some flags wrong or whatever. I was just trying to figure out whether it makes sense to use this particular issue to track that, or if it makes more sense to close it with #22167 (which is what I was intending to do).

[polarathene]

This should be closed for resolving the gcc_eh issue. My earlier comment in response to the PR was for other users and the issue author to be aware that static linking glibc will still fail.

#4986 is probably sufficient for tracking static glibc (or equivalent fix) support?