<div dir="ltr">Hi Ximin and Fabian,<div><br></div><div>Recently I sent an email about the Rust toolchain LTO issue to the Debian Rust Maintainer mailing list. Due to the high-volume nature of that list, my email communication probably did not reach you. So here is a copy of the email in case the previous one landed inside your spam folder:<br><div><br>I am Zixing Liu from Canonical. Recently it came to my attention that `dh-cargo` and the `cargo` wrapper do not honour the `DEB_BUILD_OPTIONS=optimize=-/+lto` flag.<br>Instead, whatever the project upstream defines in the `Cargo.toml` file (the `lto` parameter) takes precedence.<br><br>To better control the building parameters and avoid issues like <a href="https://github.com/rust-lang/rust/pull/89041" target="_blank">https://github.com/rust-lang/rust/pull/89041</a>, we need to be able to switch on or off LTO regardless of what the upstream project declares.<br><br>I propose adding a segment in the `dh-cargo` wrapper where we can pass the argument `--config "profile.release.lto = true/false"` to the `cargo` accordingly.<br><br>However, one thing I need some help with is the Rust toolchain's LTO option is a tri-state one, where it has `false,` `"thin,"` and `"fat"` (or "true") three possible values. In Debian, since the `DEB_BUILD_OPTIONS` is designed around GCC's conventions, it does not quite fit in our situation: `fat` may cause issues with debug information collection (see <a href="https://github.com/rust-lang/rust/pull/89041" target="_blank">https://github.com/rust-lang/rust/pull/89041</a> for more information, this is an LLVM bug that has been around for quite a while now), and `thin` may generate inferior machine code during the LTO phase when comparing to `fat.` So we can't use a 100% bullet-proof default value for the `+lto` situation.<br><br>What's your opinion on this? I can handle the implementation if we reach a conclusion.<br><br>Thanks,<br>Zixing<div class="gmail-yj6qo"></div><div class="gmail-adL"><br></div></div></div></div>