[Reproducible-builds] Link Time Optimization breaks reproducible builds

[conchur at web.de]

Hi,

I am actually not from the Debian project but may have found a reason why some
packages are not reproducible.

I wanted to create some automatic build system for mupen64plus which only
generates new tarballs when the new build binaries changed. But I've noticed
that the builds were different each time. I knew that the mupen64plus
maintainer in Debian already showed that this is possible for Windows. But the
solution for Windows is extreme specific for this platform and toolchain. So
I've wanted to look if he already solved it for the Debian builds and found the
link on tracker.debian.org which stated that there is a reproducible build
project in Debian and mupen64plus-core doesn't build reproducible.

I've tested it here on my Debian Jessie and found out that only the build id of
libmupen64plus.2.0.0 changed (and thus the debug binary link). The rest of the
file was identical (every bit). So I guessed that the build works perfectly
fine and should actually be reproducible.

I was playing around with the flags in debian/rules and removed the flag -flto
(LTO/Link Time Optimization) from DEB_CFLAGS_MAINT_APPEND because the note from
the reproducible server suggest that it is related. And now the build was
working perfectly fine and was reproducible each time I was running debuild
again.

Here is the problem: It is highly recommended to use -flto with
mupen64plus-core because otherwise the pure and cached interpreters become
quite slow (this is why the default OPTFLAGS of mupen64plus-core also contain
-flto). It would be more interesting to find why only LTO builds have this
problem. Maybe there is some kind of uninitialized memory hashed to generate
the build-id? I think I saw some 31C3 presentation which suggested that a
similar problem was fixed for normal builds.

Does anyone know how to fix this problem?

Regards,
Conchúr Navid