-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Implement -Zlink-native-libraries #70095
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
cc @cramertj |
cc @nagisa |
Sorry I don't have the time nowadays to review PRs like this, would it be possible to find someone else to take over review? |
r? @nagisa |
I have my qualms about the naming of the flag, but since its a @bors r+ |
📌 Commit bb55741 has been approved by |
@nagisa Very happy to consider other names. Did you have any thoughts/suggestions? What don't you like about this name? |
Implement -Zlink-native-libraries This implements a flag `-Zlink-native-libraries=yes/no`. If set to true/yes, or unspecified, then native libraries referenced via `#[link]` attributes will be put on the linker line (ie, unchanged behaviour). If `-Zlink-native-libraries=no` is specified then rustc will not add the native libraries to the link line. The assumption is that the outer build system driving the build already knows about the native libraries and will specify them to the linker directly (for example via `-Clink-arg=`). Addresses issue rust-lang#70093
Rollup of 9 pull requests Successful merges: - #69036 (rustc: don't resolve Instances which would produce malformed shims.) - #69443 (tidy: Better license checks.) - #69814 (Smaller and more correct generator codegen) - #69929 (Regenerate tables for Unicode 13.0.0) - #69959 (std: Don't abort process when printing panics in tests) - #69969 (unix: Set a guard page at the end of signal stacks) - #70005 ([rustdoc] Improve visibility for code blocks warnings) - #70088 (Use copy bound in atomic operations to generate simpler MIR) - #70095 (Implement -Zlink-native-libraries) Failed merges: r? @ghost
Failed in #70130 (comment), @bors r- |
@Centril I think this is going to be hard to do a true cross-platform test. I'll limit it to Unix-like for now. |
(I just paste a standard message whenever I find a PR breaks my rollup...) You'll want to make this test unix-only then; but I don't recall what the flag is atm. |
This implements a flag `-Zlink-native-libraries=yes/no`. If set to true/yes, or unspecified, then native libraries referenced via `#[link]` attributes will be put on the linker line (ie, unchanged behaviour). If `-Zlink-native-libraries=no` is specified then rustc will not add the native libraries to the link line. The assumption is that the outer build system driving the build already knows about the native libraries and will specify them to the linker directly (for example via `-Clink-arg=`). Addresses issue rust-lang#70093
Updated to add |
@bors r=nagisa |
📌 Commit 53c4e0c has been approved by |
Hmm, this should help linking to libc statically on platforms where rustc and libc crate disrespect |
☀️ Test successful - checks-azure |
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives. This is another way to address issue # rust-lang#70093, which is currently addressed by `-Zlink-native-libraries` (implemented in rust-lang#70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used. Being able to control this on a crate-by-crate basis should make it much easier to apply when needed. I'm not sure if we need both mechanisms, but we can decide that later.
Implement -Zlink-directives=yes/no `-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives. This is another way to address issue # rust-lang#70093, which is currently addressed by `-Zlink-native-libraries` (implemented in rust-lang#70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used. Being able to control this on a crate-by-crate basis should make it much easier to apply when needed. I'm not sure if we need both mechanisms, but we can decide that later. cc `@pcwalton` `@cramertj`
Originally added in rust-lang#70095.
Document -Zlink-native-libraries Originally added in rust-lang#70095.
Rollup merge of rust-lang#116213 - tmandry:doclnl, r=ehuss Document -Zlink-native-libraries Originally added in rust-lang#70095.
This implements a flag
-Zlink-native-libraries=yes/no
. If set to true/yes, or unspecified, thennative libraries referenced via
#[link]
attributes will be put on the linker line (ie, unchangedbehaviour).
If
-Zlink-native-libraries=no
is specified then rustc will not add the native libraries to the linkline. The assumption is that the outer build system driving the build already knows about the native
libraries and will specify them to the linker directly (for example via
-Clink-arg=
).Addresses issue #70093