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

Tracking issue for customizing CRT linkage #37406

Closed
alexcrichton opened this issue Oct 25, 2016 · 30 comments

Comments

Projects
None yet
@alexcrichton
Copy link
Member

commented Oct 25, 2016

Tracking issue for rust-lang/rfcs#1721

  • - Add the crt-static target-feature
  • - Update Cargo to pass through target-feature to build scripts - rust-lang/cargo#3243
  • - Implement "lazy link attributes" and implement in a gated fashion in liblibc.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 3, 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 6, 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 10, 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 10, 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 10, 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 10, 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue 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

eddyb added a commit to eddyb/rust that referenced this issue Nov 11, 2016

Rollup merge of rust-lang#37545 - alexcrichton:crt-static, r=brson
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 14, 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

bors added a commit that referenced this issue Nov 14, 2016

Auto merge of #37545 - alexcrichton:crt-static, r=brson
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 14, 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

bors added a commit that referenced this issue Nov 15, 2016

Auto merge of #37545 - alexcrichton:crt-static, r=brson
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue 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 rust-lang#37406

bors added a commit that referenced this issue Nov 15, 2016

Auto merge of #37545 - alexcrichton:crt-static, r=brson
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue 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 rust-lang#37406

bors added a commit that referenced this issue Nov 15, 2016

Auto merge of #37545 - alexcrichton:crt-static, r=brson
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue 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 rust-lang#37406

bors added a commit that referenced this issue Nov 16, 2016

Auto merge of #37545 - alexcrichton:crt-static, r=brson
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
@retep998

This comment has been minimized.

Copy link
Member

commented Jan 4, 2017

I can confirm that with an up to date libc, using this new feature out in the wild does result in binaries with the CRT statically linked.

@steveklabnik

This comment has been minimized.

Copy link
Member

commented Jan 5, 2017

So this landed in stable right? Can this be closed now?

@alexcrichton

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2017

AFAIK this feature is still gated, but I'll update the tags as such.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

Stabilization is a great place for a first PR. There are directions available on the forge:

https://forge.rust-lang.org/stabilization-guide.html

However, @alexcrichton -- are there docs available for this feature?

@steveklabnik

This comment has been minimized.

Copy link
Member

commented Mar 16, 2017

I'm not aware of any.

@alexcrichton

This comment has been minimized.

Copy link
Member Author

commented Mar 20, 2017

I've added documentation in rust-lang-nursery/reference#17

In doing so I've realized that we have another can of worms to open before we can stabilize this, unfortunately.

@alexcrichton alexcrichton referenced this issue Mar 20, 2017

Closed

Tracking issue for `cfg_target_feature` #29717

0 of 1 task complete
@binarycrusader

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2017

Be aware that some platforms do not offer a static libc, such as Solaris. Fyi.

@alexcrichton

This comment has been minimized.

Copy link
Member Author

commented May 4, 2017

This was discussed at tools triage recently and the decision was to go ahead and stabilize -C target-feature=+crt-static, but we will avoid stabilizing #[cfg] accessors as that's connected elsewhere

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 4, 2017

rustc: Stabilize `-C target-feature=+crt-static`
This commit stabilizes the `crt-static` feature accepted by the compiler. Note
that this does not stabilize the `#[cfg]` attribute for `crt-static` as
that's going to be covered by rust-lang#29717. This only stabilizes a few small pieces:

* The `crt-static` feature as accepted by the `-C target-feature` flag, and its
  connection with the platform-specific definition of `crt-static`.
* The semantics of `--print cfg` printing out activated `crt-static` feature, if
  available.

This should be enough to get the benefits of `crt-static` on stable Rust with
MSVC and with musl, but sidsteps the issue of stabilizing rust-lang#29717 first.

Closes rust-lang#37406

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 4, 2017

rustc: Stabilize `-C target-feature=+crt-static`
This commit stabilizes the `crt-static` feature accepted by the compiler. Note
that this does not stabilize the `#[cfg]` attribute for `crt-static` as
that's going to be covered by rust-lang#29717. This only stabilizes a few small pieces:

* The `crt-static` feature as accepted by the `-C target-feature` flag, and its
  connection with the platform-specific definition of `crt-static`.
* The semantics of `--print cfg` printing out activated `crt-static` feature, if
  available.

This should be enough to get the benefits of `crt-static` on stable Rust with
MSVC and with musl, but sidsteps the issue of stabilizing rust-lang#29717 first.

Closes rust-lang#37406
@alexcrichton

This comment has been minimized.

Copy link
Member Author

commented May 4, 2017

I've opened a stabilization PR to reflect this conclusion.

bors added a commit that referenced this issue May 12, 2017

Auto merge of #41757 - alexcrichton:stabilize-crt-static, r=japaric
rustc: Stabilize `-C target-feature=+crt-static`

This commit stabilizes the `crt-static` feature accepted by the compiler. Note
that this does not stabilize the `#[cfg]` attribute for `crt-static` as
that's going to be covered by #29717. This only stabilizes a few small pieces:

* The `crt-static` feature as accepted by the `-C target-feature` flag, and its
  connection with the platform-specific definition of `crt-static`.
* The semantics of `--print cfg` printing out activated `crt-static` feature, if
  available.

This should be enough to get the benefits of `crt-static` on stable Rust with
MSVC and with musl, but sidsteps the issue of stabilizing #29717 first.

Closes #37406

@bors bors closed this in #41757 May 12, 2017

citizen428 added a commit to citizen428/rust that referenced this issue May 17, 2017

rustc: Stabilize `-C target-feature=+crt-static`
This commit stabilizes the `crt-static` feature accepted by the compiler. Note
that this does not stabilize the `#[cfg]` attribute for `crt-static` as
that's going to be covered by rust-lang#29717. This only stabilizes a few small pieces:

* The `crt-static` feature as accepted by the `-C target-feature` flag, and its
  connection with the platform-specific definition of `crt-static`.
* The semantics of `--print cfg` printing out activated `crt-static` feature, if
  available.

This should be enough to get the benefits of `crt-static` on stable Rust with
MSVC and with musl, but sidsteps the issue of stabilizing rust-lang#29717 first.

Closes rust-lang#37406
@clarfon

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2017

So apparently, libc fails to compile on MUSL for me because of this feature:

error: is feature gated (see issue #37406)
   --> /home/clar/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.26/src/unix/mod.rs:227:9
    |
227 |         #[link(name = "c", kind = "static", cfg(target_feature = "crt-static"))]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(link_cfg)] to the crate attributes to enable

error: is feature gated (see issue #37406)
   --> /home/clar/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.26/src/unix/mod.rs:228:9
    |
228 |         #[link(name = "c", cfg(not(target_feature = "crt-static")))]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(link_cfg)] to the crate attributes to enable

But this appears to be stabilised? Am I missing something?

(note: this is via cargo build --release --target x86_64-unknown-linux-musl)

@steveklabnik

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

@clarcharr I believe that's because it's stable in 1.19, which is gonna get released in like 45 minutes.

@clarfon

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2017

@steveklabnik sorry, I should have clarified that this is on nightly.

@QuietMisdreavus

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

It looks like the issue is more about using the cfg(target_feature), rather than crt-static itself? Since #29717 is still open, i bet that's what's going on.

@retep998

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

libc should not be relying on the link_cfg feature except when built as part of the standard library. When built as a normal crates.io crate that attribute should not exist, which means it is likely a bug in libc.

@jirutka

This comment has been minimized.

Copy link

commented Jul 20, 2017

/cc @Shizmob

@clarfon

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2017

@retep998 I'm having trouble imagining this as a bug in libc considering how musl is a tested target; maybe a recent change triggered this?

@retep998

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

The syntax #[link(name = "c", kind = "static", cfg(target_feature = "crt-static"))] is intended to be an unstable detail only used for libc when built as part of the standard library because the standard library is compiled at a point where it does not know whether the user wants a static CRT or dynamic CRT.

As far as I can tell by looking at the code, that attribute should only even be activated during a cargo build when you've opted out of the use_std default feature. However I see that CI does test cargo build --no-default-features which makes me wonder whether it is testing that target. Because it doesn't explicitly specify --target that means.... it isn't actually testing that target until it does the docker tests, which never build the crate with --no-default-features!

@clarfon

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2017

aha!

I'll link this in a comment on libc to point out that the musl build is indeed failing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.