Repository navigation
unable to find Static system library 'gcc_eh' #17268
Description
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 --verboseI 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
Activity
polarathene commentedon Mar 7, 2024
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 buildvszig ccis a different story it seems)It's more likely to be an incompatibility with howcargo-zigbuildis implemented?libgcc/gcc_ehare related to internals with the rust compiler orcargoIIRC. Perhaps there is some logic there that needs to be carried over tocargo-zigbuild🤷♂️EDIT: I am partially wrong.
hello.cwith static linking (the advice there doesn't seem to apply tolibc.aas it'd compile but segfault when run on the same build host).ccstatic build support beforecargo-zigbuildcan do anything about it.alexrp commentedon Dec 6, 2024
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 commentedon Dec 6, 2024
@alexrp while that will resolve the linking issue, AFAIK
zig ccwill still enforce dynamic linking forglibcand static linking formusl.Anyone that lands here when this issue is closed will want to still only use
muslfor static builds.Normally you would want to be wary of
glibcstatic linking of course as there are known caveats, but for Rust there iseyrawhich hooks into the-gnu/glibctarget 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?
eyrawould provide it's own IIRC (Buildingeyrawithout Zig still requires a linker flag-nostartfiles).alexrp commentedon Dec 6, 2024
Is this the only open issue we have tracking static glibc support? If so, the issue title is somewhat suboptimal...
polarathene commentedon Dec 6, 2024
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
cargopackage build modified for example to patch the musl target to dynamic link by default instead).andrewrk commentedon Dec 6, 2024
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 commentedon Dec 6, 2024
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.
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 tozig ccwith Rust), this one in particular seems to be relevant (focused on musl with later comments suggesting workarounds that would not work for eyra).andrewrk commentedon Dec 6, 2024
Yeah sure, I buy that argument.
My above comment is mainly in response to @alexrp.
alexrp commentedon Dec 6, 2024
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 commentedon Dec 6, 2024
This should be closed for resolving the
gcc_ehissue. 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?