Tracking issue for customizing CRT linkage #37406

alexcrichton · 2016-10-25T16:28:23Z

- Add the crt-static target-feature
- Update Cargo to pass through target-feature to build scripts - Expose rustc cfg values to build scripts cargo#3243
- Implement "lazy link attributes" and implement in a gated fashion in liblibc.

Be aware that "lazy link attributes" (#[link(name = "foo", cfg(foo))]) will never be stable.

The text was updated successfully, but these errors were encountered:

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

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

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

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 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

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 · 2017-01-04T19:01:49Z

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 · 2017-01-05T22:58:16Z

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

alexcrichton · 2017-01-05T23:29:43Z

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

alexcrichton · 2017-05-04T21:03:47Z

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

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

clarfonthey · 2017-07-20T04:58:40Z

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 · 2017-07-20T15:22:51Z

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

clarfonthey · 2017-07-20T15:28:41Z

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

QuietMisdreavus · 2017-07-20T15:30:42Z

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 · 2017-07-20T15:38:55Z

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 · 2017-07-20T16:15:26Z

/cc @shizmob

clarfonthey · 2017-07-20T16:17:29Z

@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 · 2017-07-20T16:44:38Z

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!

clarfonthey · 2017-07-20T16:47:20Z

aha!

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

varkor · 2020-04-03T17:01:31Z

This issue is still linked to in errors for #[link(cfg(foo))], so shouldn't it still be open?

petrochenkov · 2020-05-09T17:56:09Z

@varkor

This issue is still linked to in errors for #[link(cfg(foo))], so shouldn't it still be open?

It's better to make a new issue (or remove reference to this issue from the feature gate).

varkor · 2020-05-09T18:50:22Z

I've opened #72059, though I haven't had time to look into the state of this feature.

Remove issue number for `link_cfg` Fixes rust-lang#72059 Per rust-lang#37406 and its [unstable book entry](https://doc.rust-lang.org/beta/unstable-book/language-features/link-cfg.html), this is an internal feature, and therefore perma-unstable and not being tracked

alexcrichton added A-tools B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Oct 25, 2016

briansmith mentioned this issue Oct 26, 2016

Observe CARGO_CFG_TARGET_* in build.rs briansmith/ring#322

Closed

alexcrichton mentioned this issue Nov 3, 2016

rustc: Implement #[link(cfg(..))] and crt-static #37545

Merged

thijsc mentioned this issue Nov 15, 2016

Alpine Linux support appsignal/appsignal-elixir#16

Closed

alexcrichton added B-unstable Blocker: Implemented in the nightly compiler and unstable. T-tools and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Jan 5, 2017

alexcrichton mentioned this issue May 4, 2017

rustc: Stabilize -C target-feature=+crt-static #41757

Merged

bors closed this as completed in #41757 May 12, 2017

brson mentioned this issue Jun 8, 2017

Updated releases notes for 1.19 #42503

Closed

clarfonthey mentioned this issue Jul 20, 2017

Won't compile on musl without libstd rust-lang/libc#684

Closed

vorner mentioned this issue Jul 23, 2017

Looks for static musl despite -C target-feature=-crt-static rust-lang/libc#691

Closed

CarePackage17 mentioned this issue Jan 11, 2019

Windows CRT linking behavior in no_std build rust-lang/libc#1203

Closed

rbtcollins mentioned this issue May 14, 2019

x86_64-pc-windows-gnu/rustup-init.exe should suggest x86_64-pc-windows-gnu as the default host triple rust-lang/rustup#1851

Open

jgriebler mentioned this issue Aug 9, 2019

Linker error for no_std binary using musl #58163

Open

JohnTitor mentioned this issue Feb 29, 2020

Clean up unstable book #69561

Merged

jonas-schievink mentioned this issue Mar 30, 2020

Update the description of the ticket to point at RFC 1721 #70576

Merged

varkor mentioned this issue May 9, 2020

link_cfg feature gate is associated to closed issue #72059

Closed

petrochenkov mentioned this issue May 10, 2020

rustc-book: Document -C target-feature=+crt-static #71586

Closed

petrochenkov mentioned this issue May 23, 2020

Consider making cfg(feature = "crt-static") available *only* for link-time configuration #72510

Open

clubby789 mentioned this issue Feb 28, 2023

Remove issue number for link_cfg #108549

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for customizing CRT linkage #37406

Tracking issue for customizing CRT linkage #37406

alexcrichton commented Oct 25, 2016 •

edited by estebank

Loading

retep998 commented Jan 4, 2017

steveklabnik commented Jan 5, 2017

alexcrichton commented Jan 5, 2017

alexcrichton commented May 4, 2017

clarfonthey commented Jul 20, 2017 •

edited

Loading

steveklabnik commented Jul 20, 2017

clarfonthey commented Jul 20, 2017

QuietMisdreavus commented Jul 20, 2017 •

edited

Loading

retep998 commented Jul 20, 2017

jirutka commented Jul 20, 2017

clarfonthey commented Jul 20, 2017

retep998 commented Jul 20, 2017

clarfonthey commented Jul 20, 2017

varkor commented Apr 3, 2020 •

edited

Loading

petrochenkov commented May 9, 2020

varkor commented May 9, 2020

Tracking issue for customizing CRT linkage #37406

Tracking issue for customizing CRT linkage #37406

Comments

alexcrichton commented Oct 25, 2016 • edited by estebank Loading

retep998 commented Jan 4, 2017

steveklabnik commented Jan 5, 2017

alexcrichton commented Jan 5, 2017

alexcrichton commented May 4, 2017

clarfonthey commented Jul 20, 2017 • edited Loading

steveklabnik commented Jul 20, 2017

clarfonthey commented Jul 20, 2017

QuietMisdreavus commented Jul 20, 2017 • edited Loading

retep998 commented Jul 20, 2017

jirutka commented Jul 20, 2017

clarfonthey commented Jul 20, 2017

retep998 commented Jul 20, 2017

clarfonthey commented Jul 20, 2017

varkor commented Apr 3, 2020 • edited Loading

petrochenkov commented May 9, 2020

varkor commented May 9, 2020

alexcrichton commented Oct 25, 2016 •

edited by estebank

Loading

clarfonthey commented Jul 20, 2017 •

edited

Loading

QuietMisdreavus commented Jul 20, 2017 •

edited

Loading

varkor commented Apr 3, 2020 •

edited

Loading