Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default to integrated rust-lld linker for UEFI targets #58976

Merged
merged 1 commit into from
Mar 16, 2019

Conversation

phil-opp
Copy link
Contributor

@phil-opp phil-opp commented Mar 6, 2019

The x86_64-unknown-uefi target was added in #56769 with the linker defaulting to lld-link. This means that a system linker with that name is required for linking.

I think defaulting to rust-lld, which is shipped with Rust, is a better default for the following reasons:

  • Most systems don't have lld-link installed, so it forces users to install it first.
  • The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu apt install lld leads to an executable named lld-link-6.0.
  • We already default to rust-lld for many targets, including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like x86_64-unknown-uefi is the only target that uses lld-link.)

cc @dvdhrm who added the target and @KKK669 who proposed to use rust-lld.

@rust-highfive
Copy link
Collaborator

r? @varkor

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 6, 2019
@varkor
Copy link
Member

varkor commented Mar 6, 2019

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned varkor Mar 6, 2019
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Mar 7, 2019

📌 Commit 876258b has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Mar 7, 2019

🌲 The tree is currently closed for pull requests below priority 500, this pull request will be tested once the tree is reopened

@bors 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 Mar 7, 2019
@dvdhrm
Copy link
Contributor

dvdhrm commented Mar 8, 2019

I don't have any preferences, I am fine with either. I am a bit confused why a linker needs to be bundled, but I guess it makes life easier. Regardless, it would be cool to include the justification from your PR in the commit message, so git blame and friends will give more information.

Thanks a lot for getting back on this!

@phil-opp
Copy link
Contributor Author

phil-opp commented Mar 8, 2019

I think bors adds the PR description to the merge commit, so it should show up in git blame.

kennytm added a commit to kennytm/rust that referenced this pull request Mar 11, 2019
Default to integrated `rust-lld` linker for UEFI targets

The `x86_64-unknown-uefi` target was added in rust-lang#56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.

I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:

- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)

cc @dvdhrm who added the target and @KKK669 who [proposed to use `rust-lld`](rust-lang#56769 (comment)).
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Mar 14, 2019
Default to integrated `rust-lld` linker for UEFI targets

The `x86_64-unknown-uefi` target was added in rust-lang#56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.

I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:

- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)

cc @dvdhrm who added the target and @KKK669 who [proposed to use `rust-lld`](rust-lang#56769 (comment)).
kennytm added a commit to kennytm/rust that referenced this pull request Mar 15, 2019
Default to integrated `rust-lld` linker for UEFI targets

The `x86_64-unknown-uefi` target was added in rust-lang#56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.

I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:

- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)

cc @dvdhrm who added the target and @KKK669 who [proposed to use `rust-lld`](rust-lang#56769 (comment)).
kennytm added a commit to kennytm/rust that referenced this pull request Mar 16, 2019
Default to integrated `rust-lld` linker for UEFI targets

The `x86_64-unknown-uefi` target was added in rust-lang#56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking.

I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons:

- Most systems don't have `lld-link` installed, so it forces users to install it first.
- The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`.
- We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.)

cc @dvdhrm who added the target and @KKK669 who [proposed to use `rust-lld`](rust-lang#56769 (comment)).
bors added a commit that referenced this pull request Mar 16, 2019
Rollup of 37 pull requests

Successful merges:

 - #58854 (appveyor: Use VS2017 for all our images)
 - #58855 (std: Spin for a global malloc lock on wasm32)
 - #58873 (Fix "Auto-hide item methods documentation" setting)
 - #58901 (Change `std::fs::copy` to use `copyfile` on MacOS and iOS)
 - #58933 (Move alloc::prelude::* to alloc::prelude::v1, make alloc a subset of std)
 - #58938 (core: ensure VaList passes improper_ctypes lint)
 - #58941 (MIPS: add r6 support)
 - #58949 (SGX target: Expose thread id function in os module)
 - #58959 (Add release notes for PR #56243)
 - #58976 (Default to integrated `rust-lld` linker for UEFI targets)
 - #59009 (Fix SGX implementations of read/write_vectored.)
 - #59025 (Fix generic argument lookup for Self)
 - #59036 (Fix ICE in MIR pretty printing)
 - #59037 (Avoid some common false positives in intra doc link checking)
 - #59072 (we can now skip should_panic tests with the libtest harness)
 - #59079 (add suggestions to invalid macro item error)
 - #59082 (A few improvements to comments in user-facing crates)
 - #59102 (Consistent naming for duration_float methods and additional f32 methods)
 - #59118 (rustc: fix ICE when trait alias has bare Self)
 - #59139 (Unregress using scalar unions in constants.)
 - #59146 (Suggest return lifetime when there's only one named lifetime)
 - #59147 (Make std time tests more robust for platform differences)
 - #59152 (Stabilize Range*::contains.)
 - #59156 ([wg-async-await] Add regression test for #55809.)
 - #59158 (Revert "Don't generate minification variable if minification disabled")
 - #59169 (Add `-Z allow_features=...` flag)
 - #59173 (bootstrap: Default to a sensible llvm-suffix.)
 - #59175 (Don't run test launching `echo` since that doesn't exist on Windows)
 - #59180 (Use try blocks in rustc_codegen_ssa)
 - #59185 (No old chestnuts in iter::repeat docs)
 - #59201 (Remove restriction on isize/usize in repr(simd))
 - #59204 (Output diagnostic information for rustdoc)
 - #59206 (Improved test output)
 - #59208 (Reduce a Code Repetition Related to Bit Operation)
 - #59212 (Add x86_64 musl host to the manifest)
 - #59221 (Option and Result: Add references to documentation of as_ref and as_mut)
 - #59231 (Stabilize Option::copied)
@bors bors merged commit 876258b into rust-lang:master Mar 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants