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

[otavio]

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

[camelid]

Could you provide a reproduction?

[camelid]

And also the version you're testing with?

[otavio]

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.

[mati865]

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]

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]

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

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]

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]

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]

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

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

[Mark-Simulacrum]

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]

cc @XAMPPRocky for the relnotes label

[mati865]

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]

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.

[Mark-Simulacrum]

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

[Aloso]

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.

[Rudxain]

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