conc...@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 . 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. : https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html -- Lunar .''`. lu...@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-
Description: Digital signature
_______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds