Failure compiling Fuchsia compiler

[AdrianDanis]

Building the Rust compiler for Fuchsia fails with an error when building libunwind since . I don't have a fully minimal set of build steps (actual steps are documented in https://fuchsia.dev/fuchsia-src/development/build/rust_toolchain?hl=en), but one relevant piece of the config.toml is that we set llvm-libunwind = "in-tree"

When running x.py the build fails with

Building stage2 std artifacts (x86_64-unknown-linux-gnu -> aarch64-fuchsia)
   Compiling cc v1.0.69
   Compiling core v0.0.0 (/b/s/w/ir/x/w/fuchsia-third_party-rust/library/core)
   Compiling libc v0.2.116
   Compiling memchr v2.4.1
   Compiling std v0.0.0 (/b/s/w/ir/x/w/fuchsia-third_party-rust/library/std)
   Compiling compiler_builtins v0.1.70
   Compiling unwind v0.0.0 (/b/s/w/ir/x/w/fuchsia-third_party-rust/library/unwind)
   Compiling profiler_builtins v0.0.0 (/b/s/w/ir/x/w/fuchsia-third_party-rust/library/profiler_builtins)
   Compiling rustc-std-workspace-core v1.99.0 (/b/s/w/ir/x/w/fuchsia-third_party-rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/b/s/w/ir/x/w/fuchsia-third_party-rust/library/alloc)
   Compiling cfg-if v0.1.10
   Compiling adler v0.2.3
   Compiling rustc-demangle v0.1.21
error: overriding linking modifiers from command line is not supported
  --> library/unwind/src/libunwind.rs:96:1
   |
96 | / extern "C-unwind" {
97 | |     pub fn _Unwind_Resume(exception: *mut _Unwind_Exception) -> !;
98 | | }
   | |_^

This happens building the Rust compiler since b75f384 was merged, and does not happen on any commit prior to that. Any newer commit can also be made to work by just reverting 1004783 so this seems to be caused by #93901

Running x.py -v shows

"/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--crate-name" "unwind" "--edition=2021" "library/unwind/src/lib.rs" "--error-format=json" "--json=diagnostic-rendered-ansi,artifacts,future-incompat" "--crate-type" "lib" "--emit=dep-info,metadata,link" "-C" "opt-level=3" "-C" "embed-bitcode=no" "-C" "codegen-units=1" "-C" "debuginfo=2" "--cfg" "feature=\"llvm-libunwind\"" "-C" "metadata=7bb16b80dd794b17" "-C" "extra-filename=-7bb16b80dd794b17" "--out-dir" "/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/deps" "--target" "aarch64-fuchsia" "-L" "dependency=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/deps" "-L" "dependency=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/release/deps" "--extern" "cfg_if=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/deps/libcfg_if-9d1324248f6fe0fb.rmeta" "--extern" "compiler_builtins=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/deps/libcompiler_builtins-f51c9f6078312b82.rmeta" "--extern" "core=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/deps/libcore-2599389f0623040c.rmeta" "--extern" "libc=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/deps/liblibc-91b3aeedfc9688eb.rmeta" "--remap-path-prefix" "/home/adanis/test_rust_build=rustlib/src/rust" "-C" "link-arg=--sysroot=/home/adanis/test_rust_build/cipd/sdk/arch/arm64/sysroot" "-Lnative=/home/adanis/test_rust_build/cipd/sdk/arch/arm64/sysroot/lib" "-Lnative=/home/adanis/test_rust_build/cipd/sdk/arch/arm64/lib" "-C" "panic=abort" "-C" "force-unwind-tables=yes" "-Csymbol-mangling-version=legacy" "-Zunstable-options" "-Zunstable-options" "--check-cfg=names()" "--check-cfg=values()" "--check-cfg=values(bootstrap)" "--check-cfg=values(stdarch_intel_sde)" "--check-cfg=values(no_fp_fmt_parse)" "--check-cfg=values(no_global_oom_handling)" "--check-cfg=values(freebsd12)" "--check-cfg=values(backtrace_in_libstd)" "--check-cfg=values(target_env,\"libnx\")" "--check-cfg=values(target_os,\"watchos\")" "--check-cfg=values(target_arch,\"asmjs\",\"spirv\",\"nvptx\",\"nvptx64\",\"le32\",\"xtensa\")" "--check-cfg=values(dont_compile_me)" "-Zmacro-backtrace" "-Zsave-analysis" "-Cprefer-dynamic" "-Cembed-bitcode=yes" "-Zcrate-attr=doc(html_root_url=\"https://doc.rust-lang.org/nightly/\")" "-Z" "binary-dep-depinfo" "-l" "unwind" "-L" "native=/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2-std/aarch64-fuchsia/release/build/compiler_builtins-73408b68b88664ba/out" "-Wrust_2018_idioms" "-Wunused_lifetimes" "-Wsemicolon_in_expressions_from_macros" "-Dwarnings" "--sysroot" "/home/adanis/test_rust_build/fuchsia-build/x86_64-unknown-linux-gnu/stage2" "-Z" "force-unstable-if-unmarked"

And the main thing of interest there is the -l unwind that for a Fuchsia build with in-tree libunwind does not match the modifiers in libunwind and so the error therefore occurs.

I can manually make that invocation work by either dropping the -l unwind or adding the modifier via -l unwind,-bundle, but I don't know how to do that as part of the actual build so I'm not sure if that is the last issue.

From my inexperienced perspective linking against libunwind when building libunwind seems incorrect, but perhaps that's correct and there's something else going wrong?

[petrochenkov]

I suggest removing println!("cargo:rustc-link-lib=unwind"); for Fuchsia from the build script (library\unwind\build.rs).
It's unnecessary since the library is already linked using #[link] attributes.
(I would prefer not to do this myself because I don't want to prepare a testing setup for Fuchsia.)

As for the "overriding linking modifiers" error, it was indeed made too conservative in the stabilization PR #93901, I'll prepare a PR relaxing it.
UPD: The relaxation happens in #94962, until that PR lands it should be always possible to reorganize link attributes and command line options to avoid passing the same library from the command line more than once, if it's not possible then please report such case.

[AdrianDanis]

Thanks for the suggestion. Editing the build script locally seems to work, will check if that's the preferred long term approach.

For what it's worth I also tested #94962 and it resolves the issue.