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

Add option to allow #[link] directives to be ignored #70093

Closed
jsgf opened this issue Mar 18, 2020 · 1 comment
Closed

Add option to allow #[link] directives to be ignored #70093

jsgf opened this issue Mar 18, 2020 · 1 comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jsgf
Copy link
Contributor

jsgf commented Mar 18, 2020

In a non-Cargo build system (eg Buck) dependencies on native libraries are already defined in the build system. As such the build system will automatically put those libraries on the link line, which means that rustc should not do so. It would be nice to have an option to allow this (proposal: -Zlink-native-libraries=yes/no, to be stabilized as -Clink-native-libraries=yes/no).

Idea mentioned in #64191
cc @cramertj

jsgf added a commit to jsgf/rust that referenced this issue Mar 18, 2020
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
@jonas-schievink jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 18, 2020
Centril added a commit to Centril/rust that referenced this issue Mar 19, 2020
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
jsgf added a commit to jsgf/rust that referenced this issue Mar 27, 2020
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
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 28, 2020
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
@jsgf
Copy link
Contributor Author

jsgf commented May 31, 2021

Resolved by #70095

@jsgf jsgf closed this as completed May 31, 2021
jsgf added a commit to jsgf/rust that referenced this issue Feb 22, 2023
`-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.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Feb 25, 2023
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`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants