LTO ignored for all crate types when building multiple crate types and one doesn't support it

[fitzgen]

https://github.com/rustwasm/rust_wasm_template has

[lib]
crate-type = [
  # Build a cdylib to make a `.wasm` library.
  "cdylib",
  # Build an rlib for testing and benching.
  "rlib"
]

[profile.release]
lto = true

The lto = true is ignored for everything because rlibs don't support LTO. I would expect that the cdylib has LTO and that only the rlib ignores the LTO options.

@alexcrichton tells me this is a rust compiler bug, not a cargo bug.

FWIW, this command does not work either:

cargo rustc -- -C lto=fat --crate-type cdylib

[alexcrichton]

The error originates from this location when we're executing LTO

The general idea is that if you emit both a cdylib and and rlib then rustc should "do the right thing" in terms of object files. This means that the rlib is created with object files that weren't LTO'd together. Right now the backend is structured in such a way that it only sends one set of object files to the linking phase, but a change like this would require some refactorings to send a set of object files per crate type. That way the rlib crate type would receive pre-LTO object files and the cdylib would receive the post-LTO object files. (afterwards everything would get cleaned up)

[thefallentree]

do we have an fix for this issue?

[thefallentree]

A possible work around is to keep the original library as rlib, create an wrapper library that outputs staticlib, and have your lto required targets link to that.

[matklad]

Minimized example:

$ cat main.rs 
pub extern "C" fn f() -> i32 { 92 }
$ rustc -C lto=fat --crate-type rlib main.rs
$ rustc -C lto=fat --crate-type cdylib main.rs
$ rustc -C lto=fat --crate-type rlib,cdylib main.rs
error: lto can only be run for executables, cdylibs and static library outputs

error: aborting due to previous error
$ rustc --version
rustc 1.54.0-beta.1 (bf62f4de3 2021-06-23)

Both crate types work in isolation, but break together.

[jasonsewall]

I've hit this issue myself and I would like to know if there is any inclination to address this or not.

[danielsn]

Same, we're hitting this issue, would be interested in knowing if a fix is planned.

[yurivish]

I also encountered this issue.

A workaround is to use cargo rustc instead of cargo build for builds, passing an explicit crate-type to override the ["rlib", "cdylib"] options in Cargo.toml:

cargo rustc --crate-type cdylib --target wasm32-unknown-unknown

There might be some unanticipated downsides to this approach but it seems to work and builds the .wasm output without ignoring the LTO setting.