error: options -C bitcode-in-rlib=no and -C lto are incompatible

[chinedufn]

I recently updated to the latest nightly a couple of days ago and started getting an error when trying to build a crate.

error: options `-C bitcode-in-rlib=no` and `-C lto` are incompatible

The build command that I'm using is:

RUSTFLAGS="-C lto" cargo build -p my-crate-name --target x86_64-unknown-linux-gnu --release

Version info (I've tried this on MacOS as well, also fails)

$ rustc -V
rustc 1.45.0-nightly (7f65393b9 2020-05-01)
$ cargo -V
cargo 1.45.0-nightly (258c89644 2020-04-30)
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.8 (stretch)
Release:	9.8
Codename:	stretch

I see that there was some recent work around optimizing bitcode in rlibs (example: #66961 ), so that could be related but I'm not sure.

---

As far as I can tell I'm not setting -C bitcode-in-rlib=no anywhere - unless there's some way that it can be set by default in some scenarios?

Minimal Reproduction Steps

cargo new rlib-test
cd rlib-test
RUSTFLAGS="-C lto" cargo build --release
# error: options `-C bitcode-in-rlib=no` and `-C lto` are incompatible

Works fine on nightly-2020-03-01.
(I didn't check any other nightly releases in between March and May)

[Mark-Simulacrum]

Is there a reason you're passing LTO via rustflags instead of setting it in Cargo.toml? That's the recommended approach, and should work I believe.

[chinedufn]

Reason is that I don't always want LTO when building for release so by using RUSTFLAGS I can configure that without needing to edit source files whenever I want to enable/disable LTO.

Some more tangible scenarios in my own codebase:

• Fat LTO for production release builds
• Thin LTO when running the application locally
• Thin LTO when iterating on benchmarks

So the different scripts that power these things either set or don't set certain RUSTFLAGS

[Mark-Simulacrum]

You can set CARGO_PROFILE_<name>_LTO in the environment instead of rustflags to override the profile option (it takes the same values as the key in the profile).

[chinedufn]

Woah thanks never knew about that!

I suppose I'll leave the issue open since RUSTFLAGS="-C LTO" no longer works (unless that's intended?)

But your answer solves my problems so I'm personally good to go.

Thanks!

[Mark-Simulacrum]

cc @alexcrichton @nnethercote -- this is at least to me unexpected fallout but I personally think that just recommending people not set lto via RUSTFLAGS is reasonable (and instead use the environment variable overrides for Cargo).

[alexcrichton]

While not necessarily intentional it's going to be pretty hard to keep this working given the changes we have to Cargo in the pipeline. You'll likely want to use the profile env vars because Cargo has much more intrusive knowledge of LTO now for compile time speedups. This is definitely a regression but I would hope that we could rely on users moving to the profile env vars for both updated builds and compile time wins.

[Mark-Simulacrum]

I'm going to go ahead and close this as won't fix but cc @XAMPPRocky -- I've tagged this relnotes as a compat note, will it get picked up?

[XAMPPRocky]

Currently no, the relnotes tool only looks at pull requests, but I was already planning a small rewrite that will change that. If I don't get to that in time however I have saved this issue so I don't forget to include it.