Open Bug 1561797 Opened 5 years ago Updated 2 years ago

mingw error linking Rust program --enable-long-section-names

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: agashlin, Unassigned)

Details

(Keywords: in-triage)

I'm testing out builds of a standalone Rust executable using RUST_PROGRAMS (see bug 1515451), I've encountered the following error in the MinGW-Clang (tier-2) Windows build:

INFO -  error: linking with `/builds/worker/workspace/build/src/build/cargo-linker` failed: exit code: 1
INFO -    = note: "/builds/worker/workspace/build/src/build/cargo-linker" "-Wl,--enable-long-section-names" [...]
INFO -    = note: lld: error: unknown argument: --enable-long-section-names

https://treeherder.mozilla.org/#/jobs?repo=try&revision=194ca10bb239c806c2abd93f2d7d4cf772d2192a&selectedJob=253614227

I'll keep trying to debug.

I'm not sure of the exact issue here, but it looks like cargo is adding that flag (I can't find a mention of it in our build system).

Priority: -- → P3

Hm so for MinGW we expect to be invoking binutils ld but it looks like lld (LLVM's linker) is being invoked instead. Is this perhaps an LLVM-based MinGW toolchain you're using agashlin? Or perhaps the targets aren't configured right and the wrong linker is being invoked?

Final linking is done with the cargo-linker script, which wraps MOZ_CARGO_WRAP_LD, which is set to CC here (if CC_TYPE doesn't contain clang-cl).

And CC gets i686-w64-mingw32-clang here, so yeah, it looks like this is not using the linker MinGW expects.

I'm not sure why this wouldn't have been a problem when linking libs, it seems to be exposed with this exe. Maybe linking a lib doesn't throw in any flags that lld doesn't support?

Oh so if your compiler is i686-w64-mingw32-clang then LLD is probably the only linker installed since I believe the LLVM-based clang toolchain uses LLD as a linker for MinGW. In that case this is something I've never seen before myself (AFAIK the LLVM-based toolchain for MinGW is quite new). This is probably just a legitimate bug where rustc isn't compatible with the MinGW clang toolchain yet.

That makes sense, thanks for the background. I'll disable the update agent in MinGW builds for now, like the maintenance service, but I'll leave this bug open in case someone wants to look into it.

No longer blocks: 1515451

FYI this flag is hardcoded in Rust's windows-gnu target spec . It means one cannot change in at runtime but has to modify the spec and recompile the compiler.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.