Hi, thanks for the detailed answer. The proposed things will definitely help me. But I just got interested in the inner workings of the gcc lto stuff. So I will just ask some things just out of curiosity.
First, is there already some kind of documentation about this problem in the GCC bug tracker or in the reproducible wiki? [...] > 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. Ok, there are many make_temp_file in gcc/lto-wrapper.o these could be the source for the randomness? I just replaced my /usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper with some simple wrapper script (lto-wrapper2 is the old version): #! /bin/sh echo $COLLECT_GCC >> /tmp/collect_gcc echo "$@" >> /tmp/foobar cp $(echo "$1"|sed 's/^.//') /tmp/input /usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper2 "$@"|tee /tmp/output The arguments were: @/tmp/cciTQ4Dg The content of this file was: -fresolution=/tmp/cc27YWea.res _obj/GlideHQ/tc-1.1+/fxt1.o [...] _obj/GlideHQ/tc-1.1+/s2tc/s2tc_libtxc_dxtn.o The output was: /tmp/ccjdkQfg.ltrans0.ltrans.o [...] /tmp/ccjdkQfg.ltrans31.ltrans.o The random filenames in the final build were: 0000000000000000 l df *ABS* 0000000000000000 ccjdkQfg.ltrans0.o [...] 0000000000000000 l df *ABS* 0000000000000000 ccjdkQfg.ltrans31.o So it looks at first glance like the lto-wrapper generates the random string. Btw. the .res file doesn't contain the random string. Then I've changed the wrapper to call a different GCC_COLLECT #! /bin/sh echo $COLLECT_GCC >> /tmp/collect_gcc echo "$@" >> /tmp/foobar cp $(echo "$1"|sed 's/^.//') /tmp/input COLLECT_GCC=/usr/bin/g++-wrapper /usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper2 "$@"|tee /tmp/output the g++-wrapper was just a simple #! /bin/sh echo "$@" >> /tmp/foobarcollect g++ "$@ The output was a long list of something like: -xlto -c -fno-trapv -mmmx -msse -mtune=generic -march=x86-64 -O3 -fPIC -fexceptions -O3 -ffast-math -fno-strict-aliasing -fvisibility=hidden -D GCC -mmmx -msse -fPIC -D _REENT RANT -shared -L /usr/lib/x86_64-linux-gnu -L /usr/lib/x86_64-linux-gnu -shared-libgcc -mtune=generic -march=x86-64 -dumpdir ./ -dumpbase mupen64plus-video-glide64mk2.so.ltrans 0 -fltrans -o /tmp/ccjdkQfg.ltrans0.ltrans.o /tmp/ccjdkQfg.ltrans0.o The input already has the random name and the output just also receives it. Interestingly there is already some earlier call: @/tmp/ccjsmCwb.args The content of this file is rather long. But the only line with the relevant random string: -fltrans-output-list=/tmp/ccjdkQfg.ltrans.out My first guess is that it comes from ltrans_output_file. All these files are stored in /tmp and this makes it unsafe when these were not some kind of unique files. Otherwise on a parallel build (or another user building on that machine), the output could be overwritten or collide. Does anyone know if it maybe possible or feasible to drop these names from the resulting file? They don't seem to be relevant. Looking through the code of lto-wrapper makes it quite clear that these names are only generated on WHOPR and partitioned lto runs. I've modified debian/rules of mupen64plus-core and added following to DEB_CFLAGS_MAINT_APPEND: -flto-partition=none I have to read a little bit how the partitioning might affect the build. The random filenames seem to be gone now. *But* the debug files are still quite different. The binaries are still different in the build-id and the debug link. Regards, Conchúr Navid _______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds