Cross-compiling `rustc` with LTO enabled results in error

[topjohnwu]

I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact:

Building compiler artifacts (stage1:aarch64-apple-darwin -> stage2:x86_64-apple-darwin)
   Compiling proc-macro2 v1.0.53
   Compiling unicode-ident v1.0.5
   Compiling cfg-if v1.0.0
   Compiling unicode-xid v0.2.4
   Compiling quote v1.0.26
   Compiling syn v1.0.102
   Compiling libc v0.2.140
   Compiling once_cell v1.16.0
   Compiling stable_deref_trait v1.2.0
   Compiling proc-macro-hack v0.5.19
   Compiling smallvec v1.10.0
   Compiling ahash v0.7.4
   Compiling log v0.4.14
   Compiling indexmap v1.9.3
   Compiling parking_lot_core v0.8.5
   Compiling memchr v2.5.0
   Compiling lock_api v0.4.7
   Compiling instant v0.1.12
   Compiling scopeguard v1.1.0
   Compiling tracing-core v0.1.28
   Compiling rustc-hash v1.1.0
   Compiling pin-project-lite v0.2.8
   Compiling thiserror v1.0.38
   Compiling getrandom v0.2.8
   Compiling bitflags v1.3.2
   Compiling typenum v1.16.0
error: lto can only be run for executables, cdylibs and static library outputs

error: could not compile `proc-macro-hack` due to previous error
warning: build failed, waiting for other jobs to finish...

I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue.

Here is the config.toml I used:

changelog-seen = 2

[llvm]
download-ci-llvm = true

[build]
docs = false
submodules = false
extended = true
tools = ["cargo", "src", "clippy", "rust-analyzer", "rustfmt"]

[install]
prefix = "../out"
sysconfdir = "etc"

[rust]
lld = true
llvm-tools = true
jemalloc = true
lto = "thin"

It seems that cargo is enabling LTO for proc-macro crates, but only when cross-compiling?

[topjohnwu]

@jyn514 sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.

[jyn514]

I haven't had time to look into this, no. You can always disable LTO as a workaround.

[msrd0]

This problem also appears when just the vendor of the target tripple changes (i.e. (stage1:x86_64-unknown-linux-musl -> stage2:x86_64-alpine-linux-musl)).

[onur-ozkan]

This problem also appears when just the vendor of the target tripple changes (i.e. (stage1:x86_64-unknown-linux-musl -> stage2:x86_64-alpine-linux-musl)).

Thank you for the additional feedback, will look into this issue in couple weeks.