[Pkg-rust-maintainers] dh-cargo does not respect LTO options from DEB_BUILD_OPTIONS

[Zixing Liu]

Hi Ximin and Fabian,

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:

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.
Instead, whatever the project upstream defines in the `Cargo.toml` file
(the `lto` parameter) takes precedence.

To better control the building parameters and avoid issues like
https://github.com/rust-lang/rust/pull/89041, we need to be able to switch
on or off LTO regardless of what the upstream project declares.

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.

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
https://github.com/rust-lang/rust/pull/89041 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.

What's your opinion on this? I can handle the implementation if we reach a
conclusion.

Thanks,
Zixing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20230414/912ca4d3/attachment.htm>