Le mardi 27 octobre 2015 à 13:40 +0100, Rafael Laboissiere a écrit : > * Reiner Herrmann <reineratreiner-h.de> [2015-10-26 22:06]: > > > > [...] > > > > Here is a quick proof that the path is responsible for the differences: > > > > $ cp test.c tmp-1/ && cd tmp-1 && mkoctfile test.c && md5sum test.o && cd > > .. > > 8cd4b14fc2bab0efad22f17920d02455 test.o > > $ cp test.c tmp-1/ && cd tmp-1 && mkoctfile test.c && md5sum test.o && cd > > .. > > 8cd4b14fc2bab0efad22f17920d02455 test.o > > $ cp test.c tmp-2/ && cd tmp-2 && mkoctfile test.c && md5sum test.o && cd > > .. > > 05d17c676f643adef2c15c3899f6a4a3 test.o > > > > -> compiling the same file in the same directory leads to the same > > result, while compiling in a different path produces a different object > > file. > > > > I had a short look at it some time ago, and think that it has to be > > fixed in this file [0]. There it is creating the temporary (random) > > directories and copying the source into it. > > > > [0]: > > https://sources.debian.net/src/octave/4.0.0-5/scripts/pkg/private/install.m/?hl=67,70,96#L67 > > Thanks for your reply, Reiner. > > I think that I found the culprit. The .oct files for octave are built > using the mkoctfile program, as you pointed out above. This program uses > default values for the the environment variables containing flags for the > to C++ compilation and binary link. For instance: > > $ mkdir tmp-1 > $ cp /usr/share/doc/liboctave-dev/examples/oregonator.cc tmp-1 > $ (cd tmp-1 ; mkoctfile -v oregonator.cc) > g++ -c -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-4.0.0/octave/.. > -I/usr/include/octave-4.0.0/octave -I/usr/include/hdf5/serial > -I/usr/include/mpi -pthread -fopenmp -mieee-fp -g -O2 > -fstack-protector-strong -Wformat -Werror=format-security oregonator.cc -o > oregonator.o > g++ -shared -Wl,-Bsymbolic -o oregonator.oct oregonator.o > -L/usr/lib/i386-linux-gnu/octave/4.0.0 -L/usr/lib/i386-linux-gnu -loctinterp > -loctave -Wl,-z,relro > > I discovered that the "-g" is responsible for the difffrences in the > resulting binaries. Here is the proof: > > $ (cd ../tmp-1 ; CXXFLAGS="-g -O2 -fstack-protector-strong -Wformat > -Werror=format-security" mkoctfile oregonator.cc ; md5sum oregonator.o*) > e10495ec145b6c3f946c1728fa64afd2 oregonator.o > 641e6c9a7ee23b38a4452e6337f8a6b5 oregonator.oct > $ (cd ../tmp-2 ; CXXFLAGS="-g -O2 -fstack-protector-strong -Wformat > -Werror=format-security" mkoctfile oregonator.cc ; md5sum oregonator.o*) > ab176e529b49d9d6860b85c7ed7f228c oregonator.o > 7e3f711217a357714ec676cdee8a7f56 oregonator.oct > $ (cd ../tmp-1 ; CXXFLAGS="-O2 -fstack-protector-strong -Wformat > -Werror=format-security" mkoctfile oregonator.cc ; md5sum oregonator.o*) > 946afa562517e63a5653ba8f842ed6f2 oregonator.o > bd0d4be1b541f75dad8de2c736dce1bc oregonator.oct > $ (cd ../tmp-2 ; CXXFLAGS="-O2 -fstack-protector-strong -Wformat > -Werror=format-security" mkoctfile oregonator.cc ; md5sum oregonator.o*) > 946afa562517e63a5653ba8f842ed6f2 oregonator.o > bd0d4be1b541f75dad8de2c736dce1bc oregonator.oct > > I just committed a change to the octave-pkg-dev package for removing the > -g option form the compilation flags [1]. The DOG packages seem to have > reproducible builds now, at least as regards the binary files *.oct that > are included in the package. > > @DOG: Please, review my changes and, if you think everything is ok, I > will prepare a new version of octave-pkg-dev.
My understanding is that .oct files are stripped before creating the Debian package (by dh_strip). Hence they no longer contain debugging symbol. So removing -g at compilation time should make no difference. Did you verify that your change makes a difference on the final .debs? -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
