-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Comments
Could you provide a reproduction? |
And also the version you're testing with? |
The nightly of 2020-10-20.
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. |
This comment has been minimized.
This comment has been minimized.
It works with explicit target:
cc @petrochenkov I assume it's expected that #69519 helped only the case with explicit (aka cross-compiled) target? |
@mati865 Then cargo comes into play. AFAIK, it applies |
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? |
The mcve could be the rust-ctor repository itself.
|
Is there any reason static void *stub_dlopen(const char *file, int mode)
{
__dl_seterr("Dynamic loading not supported");
return 0;
}
weak_alias(stub_dlopen, dlopen); But |
@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? |
Assigning |
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 |
cc @XAMPPRocky for the relnotes label |
@Mark-Simulacrum to be more clear, |
I do think we need a better solution for building statically in general. Passing an explicit |
crate
as the target x86_64-unknown-linux-gnu
does not support these crate types" with +crt-static
I don't believe we're intending to fix this. |
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 |
Required for `crt-static` rustflag, see rust-lang/rust#78210
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
Now that GH supports "Closing Reasons" this should be "Closed as Not Planned" |
Build error
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
The text was updated successfully, but these errors were encountered: