Fix rust.use-lld when linker is not set by mati865 · Pull Request #76326 · rust-lang/rust

mati865 · 2020-09-04T13:32:51Z

Previously when [<target>].linker was not configured rust.use-lld would set it to rust-lld on platforms where it should not.

rust-highfive · 2020-09-04T13:32:55Z

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

mati865 · 2020-09-04T13:33:01Z

cc @petrochenkov

Mark-Simulacrum · 2020-09-04T14:39:17Z

I wonder if we should be warning folks if they do set use-lld and then we are just basically ignoring that.

mati865 · 2020-09-04T15:06:54Z

@Mark-Simulacrum Since #75111rust.use-lld will add "-Clink-args=-fuse-ld=lld" on non MSVC targets. Before this change when [<target>].linker was not set, rust.use-lld would set [<target>].linker to rust-lld and then also append "-Clink-args=-fuse-ld=lld".

Mark-Simulacrum · 2020-09-04T15:49:59Z

Ah right, okay, makes sense. I'm going to @bors r+ this then, but we can back out if people disagree. It sounds like the right thing.

bors · 2020-09-04T15:50:01Z

📌 Commit a2fbf39 has been approved by Mark-Simulacrum

petrochenkov · 2020-09-04T17:06:40Z

I can confirm that hangs in #76127 (comment) occur in winpthreads, and that rust-lld shipped with rustc was used, and this PR fixes that.

The fix however causes an error during linking

note: x86_64-w64-mingw32-gcc.exe: error: unrecognized command line option '-fuse-ld=lld'; did you mean '-fuse-ld=bfd'?

which is very strange because x86_64-w64-mingw32-gcc -fuse-ld=lld hello.c works.
Currently investigating.

$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc.exe (Rev1, Built by MSYS2 project) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ld.lld --version
LLD 10.0.1 (https://github.com/Alexpux/MINGW-packages.git 94b687508346d10cec7e8c769785f73da18b4e54) (compatible with GNU linkers)

mati865 · 2020-09-04T17:19:13Z

@petrochenkov at which stage?
Sounds like build/x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/bin/self-contained/x86_64-w64-mingw32-gcc.exe was used but this is totally wrong. Bundled linker should not be used for building Rust.

petrochenkov · 2020-09-04T17:22:39Z

Sounds like build/x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/bin/self-contained/x86_64-w64-mingw32-gcc.exe was used

Ha, maybe!
It's stage 0, ./x.py build tidy from scratch.

mati865 · 2020-09-04T17:28:15Z

I cannot test it right now but sounds like this could be fixed when #76167 lands in bootstrap compiler.
Alternatively for a quickly fix we can avoid downloading rust-mingw component in bootstrap (this will also marginally improve build times).

petrochenkov · 2020-09-04T17:30:53Z

This is indeed the reason, the ancient x86_64-w64-mingw32-gcc shipped with rustc is getting used as a linker wrapper.

petrochenkov · 2020-09-04T18:04:15Z

Alternatively for a quickly fix we can avoid downloading rust-mingw component in bootstrap (this will also marginally improve build times).

We need an external toolchain for x.py anyway to build LLVM? rust-mingw component is not enough?
Did anyone try to x.py with an external pre-build LLVM and no external C/C++ toolchain?

UPD: We have our own rust_llvm with C++ code, so we need an external toolchain and should be able to avoid downloading the rust-mingw component.

petrochenkov · 2020-09-04T18:04:19Z

(Anyway, the local workaround of nuking

build/x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/bin/self-contained
build/x86_64-pc-windows-gnu/stage0/lib/rustlib/x86_64-pc-windows-gnu/lib/self-contained

works.)

petrochenkov · 2020-09-04T19:12:40Z

Full ./x.py test --bless --stage 2 on target.x86_64-pc-windows-gnu is confirmed to pass with LLD 🎉

mati865 · 2020-09-04T20:14:32Z

Alternatively for a quickly fix we can avoid downloading rust-mingw component in bootstrap (this will also marginally improve build times).
We need an external toolchain for x.py anyway to build LLVM? rust-mingw component is not enough?
Did anyone try to x.py with an external pre-build LLVM and no external C/C++ toolchain?
UPD: We have our own rust_llvm with C++ code, so we need an external toolchain and should be able to avoid downloading the rust-mingw component.

rust-mingw doesn't have headers, assembler and ships only some of the mingw-w64 libs. It can be used only for linking.

…imulacrum Fix rust.use-lld when linker is not set Fixesrust-lang#76127 (comment) Previously when `[<target>].linker` was not configured `rust.use-lld` would set it to `rust-lld` on platforms where it should not.

petrochenkov · 2020-09-05T17:56:29Z

The rust-mingw component change is submitted in #76381.

…imulacrum Fix rust.use-lld when linker is not set Fixesrust-lang#76127 (comment) Previously when `[<target>].linker` was not configured `rust.use-lld` would set it to `rust-lld` on platforms where it should not.

bors · 2020-09-06T04:01:01Z

⌛ Testing commit a2fbf39 with merge b40abfd...

bors · 2020-09-06T06:15:22Z

☀️ Test successful - checks-actions, checks-azure
Approved by: Mark-Simulacrum
Pushing b40abfd to master...

…lacrum rustbuild: Do not use `rust-mingw` component when bootstrapping windows-gnu targets Addresses rust-lang#76326 (comment) (ancient `x86_64-w64-mingw32-gcc` is selected as a linker wrapper, which is not usable in `use_lld=true` mode). Perhaps the comment about incompatible mingw was true in the past, but many things changed since then. With this change I was able to build everything successfully locally using a newer mingw toolchain, if it passes through the older toolchain on CI, then it should be good, I think.

Fix rust.use-lld when linker is not set
a2fbf39

rust-highfive assigned Mark-Simulacrum Sep 4, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 4, 2020

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 4, 2020

Dylan-DPC-zz mentioned this pull request Sep 5, 2020
Rollup of 11 pull requests #76377
Closed

petrochenkov mentioned this pull request Sep 5, 2020
rustbuild: Do not use rust-mingw component when bootstrapping windows-gnu targets #76381
Merged

Dylan-DPC-zz mentioned this pull request Sep 5, 2020
Rollup of 11 pull requests #76394
Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 6, 2020

bors merged commit b40abfd into rust-lang:masterSep 6, 2020

rustbot added this to the 1.48.0 milestone Sep 6, 2020

bors mentioned this pull request Sep 6, 2020
rustbuild: Build tests with LLD if use-lld = true was passed #76378
Merged

mati865 deleted the use_lld-no-linker branch September 6, 2020 07:51

jyn514 added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Sep 12, 2020

Uh oh!

Uh oh!

Conversation

mati865 commented Sep 4, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Sep 4, 2020

Uh oh!

mati865 commented Sep 4, 2020

Uh oh!

Mark-Simulacrum commented Sep 4, 2020

Uh oh!

mati865 commented Sep 4, 2020

Uh oh!

Mark-Simulacrum commented Sep 4, 2020

Uh oh!

bors commented Sep 4, 2020

Uh oh!

petrochenkov commented Sep 4, 2020

Uh oh!

mati865 commented Sep 4, 2020

Uh oh!

petrochenkov commented Sep 4, 2020

Uh oh!

mati865 commented Sep 4, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Sep 4, 2020

Uh oh!

petrochenkov commented Sep 4, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Sep 4, 2020

Uh oh!

petrochenkov commented Sep 4, 2020

Uh oh!

mati865 commented Sep 4, 2020

Uh oh!

petrochenkov commented Sep 5, 2020

Uh oh!

bors commented Sep 6, 2020

Uh oh!

bors commented Sep 6, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

mati865 commented Sep 4, 2020•
edited
Loading

mati865 commented Sep 4, 2020•
edited
Loading

petrochenkov commented Sep 4, 2020•
edited
Loading