rustc: Implement #[link(cfg(..))] and crt-static #37545
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @brson |
|
I tested bootstrapping this with this commit: alexcrichton/libc@5699631. With that I was able to produce static/dynamic MSVC and musl binaries with the flip of this switch, so it's at least confirmed to work there! |
|
If possible, it would be really nice to have options for the debug versions of the CRT, |
|
☔ The latest upstream changes (presumably #37597) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
force-pushed
the
crt-static
branch
from
4487091
to
6da63c8
Compare
|
☔ The latest upstream changes (presumably #37670) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
added a commit
to alexcrichton/libc
that referenced
this pull request
Nov 10, 2016
In preparation for rust-lang/rust#37545 this is adding the appropriate directives to libc to get included.
bors
added a commit
to rust-lang/libc
that referenced
this pull request
Nov 10, 2016
Use `#[link(cfg(..))]` in preparation for libstd In preparation for rust-lang/rust#37545 this is adding the appropriate directives to libc to get included.
alexcrichton
force-pushed
the
crt-static
branch
from
6da63c8
to
f5c9fb6
Compare
|
Ok, I've updated this and now that beta has been released I went ahead and included the update to liblibc. |
|
☔ The latest upstream changes (presumably #37463) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
force-pushed
the
crt-static
branch
from
f5c9fb6
to
0d329a2
Compare
|
☔ The latest upstream changes (presumably #37542) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
force-pushed
the
crt-static
branch
2 times, most recently
from
51af985
to
aede832
Compare
|
@bors r+ |
|
📌 Commit aede832 has been approved by |
|
@bors r- Seems like we should feature-gate the |
alexcrichton
force-pushed
the
crt-static
branch
2 times, most recently
from
21d77be
to
791763b
Compare
|
@bors: r=brson Hooked up |
|
📌 Commit 791763b has been approved by |
eddyb
added a commit
to eddyb/rust
that referenced
this pull request
Nov 11, 2016
rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler, `crt-static`, which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature, `crt-static`. If enabled, then the `cfg(target_feature = "crt-static")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface, `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy, but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib, these directives are just encoded and ignored for dylibs, and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib, executable, or dylib, however, the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially, what'll happen is: * On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc rust-lang#37406
|
📌 Commit 957d3e9 has been approved by |
bors
added a commit
that referenced
this pull request
Nov 15, 2016
rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler, `crt-static`, which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature, `crt-static`. If enabled, then the `cfg(target_feature = "crt-static")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface, `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy, but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib, these directives are just encoded and ignored for dylibs, and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib, executable, or dylib, however, the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially, what'll happen is: * On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
alexcrichton
force-pushed
the
crt-static
branch
from
957d3e9
to
9a9189c
Compare
|
@bors: r=brson |
|
📌 Commit 9a9189c has been approved by |
|
⌛ Testing commit 9a9189c with merge fdb5fa1... |
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler, `crt-static`, which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature, `crt-static`. If enabled, then the `cfg(target_feature = "crt-static")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface, `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy, but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib, these directives are just encoded and ignored for dylibs, and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib, executable, or dylib, however, the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially, what'll happen is: * On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc rust-lang#37406
alexcrichton
force-pushed
the
crt-static
branch
from
9a9189c
to
06242ff
Compare
|
@bors: r=brson |
|
📌 Commit 06242ff has been approved by |
bors
added a commit
that referenced
this pull request
Nov 16, 2016
rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler, `crt-static`, which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature, `crt-static`. If enabled, then the `cfg(target_feature = "crt-static")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface, `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy, but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib, these directives are just encoded and ignored for dylibs, and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib, executable, or dylib, however, the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially, what'll happen is: * On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406
This was referenced Nov 16, 2016
This was referenced Nov 16, 2016
dstcruz
added a commit
to dstcruz/chocolatey-mypackages
that referenced
this pull request
Nov 18, 2016
This dependency requirement should go away once rust-lang/rust#37545 is implemented. I'm creating version 0.2.9.1, which points to upstream 0.2.9 as a package only version to get this dependency in.
urschrei
added a commit
to urschrei/lonlat_bng
that referenced
this pull request
Nov 20, 2016
-gnu is somewhat broken using cdylib: rust-lang/rust#37530 But we should be able to statically link msvcrt: rust-lang/rust#37545
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit is an implementation of RFC 1721 which adds a new target feature
to the compiler,
crt-static, which can be used to select how the C runtime fora target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.
This commit first adds the new target-feature,
crt-static. If enabled, thenthe
cfg(target_feature = "crt-static")will be available. Targets like muslwill have this enabled by default. This feature can be controlled through the
standard target-feature interface,
-C target-feature=+crt-staticor-C target-feature=-crt-static.Next this adds an gated and unstable
#[link(cfg(..))]feature to enable thecrt-staticsemantics we want with libc. The exact behavior of this attributeis a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.
Specifically the
#[link(cfg(..))]annotation means that the#[link]directive is only active in a compilation unit if that
cfgvalue is satisfied.For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the
cfgis evaluated as if it were defined in the final artifact and thelibrary is decided to be linked or not.
Essentially, what'll happen is:
-C target-feature=-crt-static, themsvcrt.liblibrary will belinked to.
-C target-feature=+crt-static, thelibcmt.liblibrary will belinked to.
-C target-feature=-crt-static, the object files in liblibc.rlibare removed and
-lcis passed instead.-C target-feature=+crt-static, the object files in liblibc.rlibare used and
-lcis not passed.This commit does not include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.
cc #37406