[Reproducible-builds] Link Time Optimization breaks reproducible builds

[Jérémy Bobbio]

conchur at web.de:
> 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?

Reading the description of `--build-id` in ld(1) suggests some
workarounds:

       --build-id
       --build-id=style
           Request creation of ".note.gnu.build-id" ELF
           note section.  The contents of the note are
           unique bits identifying this linked file.
           style can be "uuid" to use 128 random bits,
           "sha1" to use a 160-bit SHA1 hash on the
           normative parts of the output contents,
           "md5" to use a 128-bit MD5 hash on the
           normative parts of the output contents, or
           "0xhexstring" to use a chosen bit string
           specified as an even number of hexadecimal
           digits ("-" and ":" characters between digit
           pairs are ignored).  If style is omitted,
           "sha1" is used.

           The "md5" and "sha1" styles produces an
           identifier that is always the same in an
           identical output file, but will be unique
           among all nonidentical output files.  It is
           not intended to be compared as a checksum
           for the file's contents.  A linked file may
           be changed later by other tools, but the
           build ID bit string identifying the original
           linked file does not change.

           Passing "none" for style disables the
           setting from any "--build-id" options
           earlier on the command line.

So it should be possible to use something like
`-Wl,--build-id=0x42424242` (with a more unique id) and not depend on
the content.

Another option is to use `-Wl,--build-id=none` to remove the Build ID
entirely. TTBOMK they are only used to split debugging information in
separate files [1]. In this particular case, this would mean removing
libmupen64plus2-dbg from the binary packages.

For a proper solution, I believe a patch to GCC is needed. A trivial
test case gives me this:

    $ objdump -x f | grep \.o$
    0000000000000000 l    df *ABS*	0000000000000000 ccwqwTSn.ltrans0.o

The temporary object file created by GCC has a random name which gets
included in the final binary. If GCC could use a deterministic file
name, I believe this would solve the issue.

 [1]: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150210/70f377dd/attachment.sig>