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

"cannot produce proc-macro for crate as the target x86_64-unknown-linux-gnu does not support these crate types" with +crt-static #78210

Closed
otavio opened this issue Oct 21, 2020 · 19 comments
Labels
A-proc-macros Area: Procedural macros C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-medium Medium priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. relnotes Marks issues that should be documented in the release notes of the next release. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Milestone

Comments

@otavio
Copy link
Contributor

otavio commented Oct 21, 2020

Build error

% RUSTFLAGS="-C target-feature=+crt-static" cargo +nightly check
error: cannot produce proc-macro for `ctor v0.1.16` as the target `x86_64-unknown-linux-gnu` does not support these crate types

Version it worked on

It most recently worked on: rustc 1.48.0-beta.4 (fb94aa5 2020-10-20)

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

@rustbot rustbot added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Oct 21, 2020
@camelid
Copy link
Member

camelid commented Oct 21, 2020

Could you provide a reproduction?

@camelid camelid added A-proc-macros Area: Procedural macros T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 21, 2020
@camelid
Copy link
Member

camelid commented Oct 21, 2020

And also the version you're testing with?

@otavio
Copy link
Contributor Author

otavio commented Oct 22, 2020

And also the version you're testing with?

The nightly of 2020-10-20.

Could you provide a reproduction?

I'm out of computer now, so I can't. It seems to be related to proc macro use. I can try to cook a test case for it.

@tesuji

This comment has been minimized.

@rustbot rustbot added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Oct 22, 2020
@JohnTitor JohnTitor added the C-bug Category: This is a bug. label Oct 22, 2020
@mati865
Copy link
Contributor

mati865 commented Oct 22, 2020

It most recently worked on: rustc 1.48.0-beta.4 (fb94aa5 2020-10-20)

It did not really work but didn't produce the error since +crt-static was no-op for linux-gnu.
Since #77386 +crt-static now properly links statically.

I think I can add workaround for it.

@mati865
Copy link
Contributor

mati865 commented Oct 22, 2020

It works with explicit target:

$ RUSTFLAGS='-C target-feature=+crt-static' cargo b
error: cannot produce proc-macro for `ctor v0.1.16 (/tmp/rust-ctor/ctor)` as the target `x86_64-unknown-linux-gnu` does not support these crate types

$ RUSTFLAGS='-C target-feature=+crt-static' cargo b --target x86_64-unknown-linux-gnu
   Compiling libc v0.2.79
   Compiling proc-macro2 v0.4.30
   Compiling unicode-xid v0.1.0
   Compiling proc-macro2 v1.0.23
   Compiling syn v0.15.44
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.46
   Compiling lazy_static v1.4.0
   Compiling quote v0.6.13
   Compiling quote v1.0.7
   Compiling libc-print v0.1.14
   Compiling dlopen_derive v0.1.4
   Compiling dlopen v0.1.8
   Compiling ctor v0.1.16 (/tmp/rust-ctor/ctor)
   Compiling tests v0.1.0 (/tmp/rust-ctor/tests)
    Finished dev [unoptimized + debuginfo] target(s) in 7.14s

cc @petrochenkov I assume it's expected that #69519 helped only the case with explicit (aka cross-compiled) target?

@petrochenkov
Copy link
Contributor

petrochenkov commented Oct 22, 2020

@mati865
#69519 introduced different defaults for crt-static for executables (yes) and proc-macros (no) (should apply to all dylibs really).
If -C target-feature=+crt-static is specified explicitly, then the compiler respects it and overrides the defaults, that's the compiler's job.

Then cargo comes into play. AFAIK, it applies RUSTFLAGS only to target if --target specified explicitly, and to both target and host otherwise. (I remember people complaining about this inconsistency.)
So it doesn't pass -C target-feature=+crt-static when compiling proc macro dependencies (which is correct in this case).
I think this is a problem that should be solved at the cargo's abstraction level, in general. Cargo should provide a way to set compiler options per-crate-type and per-build-target (per-crate), and may provide its own defaults (e.g. not pass +crt-static to proc macro crates).

@otavio
Copy link
Contributor Author

otavio commented Oct 23, 2020

My biggest concern here is this looks like a regression from the user point of view; what can we currently do to workaround it until it is handled on the cargo's abtraction level, as suggested by @petrochenkov?

@otavio
Copy link
Contributor Author

otavio commented Oct 25, 2020

The mcve could be the rust-ctor repository itself.

% rustc --version
rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)
% RUSTFLAGS="-C target-feature=+crt-static" cargo test
error: cannot produce proc-macro for `ctor v0.1.16 (/home/otavio/src/rust-ctor/ctor)` as the target `x86_64-unknown-linux-gnu` does not support these crate types

@12101111
Copy link
Contributor

Is there any reason +crt-static don't work with glibc dylib (crt_static_allows_dylibs=false )? on musl this don't work because dlopen is a stub with +crt-static

static void *stub_dlopen(const char *file, int mode)
{
        __dl_seterr("Dynamic loading not supported");
        return 0;
}

weak_alias(stub_dlopen, dlopen);

But +crt-static glibc should have a functional dlopen to load nss.

@otavio
Copy link
Contributor Author

otavio commented Oct 26, 2020

@12101111 I have no idea, and it'd be good to open an issue on the project about this so that it could be fixed or documented (with a comment or so) for future people are aware of the reasoning. But does this has any relation with this specific regression?

@apiraino
Copy link
Contributor

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@apiraino apiraino added P-medium Medium priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Oct 28, 2020
@Mark-Simulacrum
Copy link
Member

Discussed in compiler team regression triage.

The regression seems to be because we're now trying to respect the new flag, which is then causing breakage. I think it is reasonable to expect users who want to build for crt-static to pass --target, because they're essentially modifying the target config they're compiling for. We likely want better diagnostics here, but that's not a regression problem. We will note this in relnotes.

@Mark-Simulacrum Mark-Simulacrum added this to the 1.48.0 milestone Nov 6, 2020
@Mark-Simulacrum Mark-Simulacrum added the relnotes Marks issues that should be documented in the release notes of the next release. label Nov 6, 2020
@Mark-Simulacrum
Copy link
Member

cc @XAMPPRocky for the relnotes label

@mati865
Copy link
Contributor

mati865 commented Nov 6, 2020

The regression seems to be because we're now trying to respect the new flag, which is then causing breakage.

@Mark-Simulacrum to be more clear, -C target-feature=+crt-static is not a new flag. It existed for a long long time but *-linux-gnu targets were ignoring it until recently.

@joshtriplett
Copy link
Member

I do think we need a better solution for building statically in general.

Passing an explicit --target is a workaround. We should have better handling for host vs target, as @petrochenkov suggested.

@joshtriplett joshtriplett changed the title dynlib stopped building on nightly "cannot produce proc-macro for crate as the target x86_64-unknown-linux-gnu does not support these crate types" with +crt-static Nov 15, 2020
@Mark-Simulacrum
Copy link
Member

I don't believe we're intending to fix this.

@Aloso
Copy link
Contributor

Aloso commented Apr 10, 2023

I ran into this recently. Is there a way to provide a better error message? It wasn't obvious to me that I have to pass --target x86_64-unknown-linux-gnu when I want to statically link libc.

danieldk pushed a commit to danieldk/sentencepiece that referenced this issue Jul 21, 2023
Required for `crt-static` rustflag, see rust-lang/rust#78210
tiibun added a commit to tiibun/xlconv that referenced this issue Jul 23, 2023
lmbarros added a commit to product-os/flowzone that referenced this issue Mar 6, 2024
The motivation for this change was to allow us to properly request the C
Runtime (CRT) to be statically linked.

In summary, each target defaults to either static or dynamic CRT
linking, but we can request static linking regardless of defaults by
using the `crt-static` target feature. The usual way to achieve that is
setting the `RUSTFLAGS="-C target-feature=+crt-static"` environment
variable. (See
https://doc.rust-lang.org/reference/linkage.html#static-and-dynamic-c-runtimes)

Rust projects using Flowzone can already do that by using `cross` for
building and setting the environment variable in a `Cross.toml` file
(see
https://github.com/cross-rs/cross/blob/main/docs/environment_variables.md#environment-variable-passthrough).

So far so good. The problem is, the `--target` option is required when
using `crt-static`, and Flowzone was not passing it to `cargo clippy`.
(See
https://msfjarvis.dev/posts/building-static-rust-binaries-for-linux/ for
an overview of the issue, and
rust-lang/rust#78210 (comment)
for some more specific details.)

Signed-off-by: Leandro Motta Barros <leandro@balena.io>
Change-type: patch
@Rudxain
Copy link
Contributor

Rudxain commented Jun 17, 2024

Now that GH supports "Closing Reasons" this should be "Closed as Not Planned"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-proc-macros Area: Procedural macros C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-medium Medium priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. relnotes Marks issues that should be documented in the release notes of the next release. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests