On Wed, Jul 24, 2019 at 06:03:21PM +0200, Steffen Möller wrote:
> Hello,
>
> We just had SuSE embracing LTO
> (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html).
> I am not sure about the progress on issues summarised in
> http://blog.regehr.org/archives/1180 that Ian pointed to. But since I
> last asked in 2016 we have more pedantic compiler settings and more CI -
> and LTO, as much as compilers have improved on that, does not need to be
> applied everywhere. Any change in opinion?
I'm currently compiling e2fsprogs with LTO for Debian --- and I'm
seriously considering ditching that change. The reason why is because
LTO breaks reproducible builds, and so it makes it harder when I'm
verifying whether a particular packaging change (say, moving to a new
debhelper compat level) is going to make any changes to the binary ---
because using LTO pretty much guarantees that it will.
Yeah, the binaries are a little bit smaller, and presumably a little
bit more CPU efficient, but 99% of the time, e2fsprogs binary are I/O
bound, not CPU bound, and the fact that my package builds aren't
reproducible is !@#?! annoying.
- Ted
