Re: Reproducible builds
Od: André Hentschel <nerv(a)dawncrow.de>
Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: > Anyway, there are 7 files out of 2750 which _always_ pickup some random > value and use that consistently. Why are these libraries built > inconsitently? Is that intentional? An example is attached.
Thanks. These "random" value come from:
* olepro_t.res * std_ole_v2_t.res * wuapi_tlb_t.res
When i do:
export WIDL_TIME_OVERRIDE="0" rm dlls/olepro32/olepro_t.res make -k dlls/olepro32 md5sum -b dlls/olepro32/olepro_t.res
then i always get different MD5 checksum.
Marcus, could you send me your dlls/olepro32/Makefile please? What is your distro?
I tried above for both 32bit and 64bit directories, always gives the same md5 in those.
openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4
I can reproduce the bug with the instructions above Linux Mint 18.1, gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4), binutils 2.26.1, flex 2.6, biso 3.0.4 the first bad value is at offset 269h Which is datatype2 from MSFT_TypeInfoBase
So initializing datatype2 in add_typedef_typeinfo or the following patch fixes the problem for me:
diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 137bb2d..7904e45 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -798,6 +798,7 @@ static int encode_type( if (!alignment) alignment = &scratch; if (!decoded_size) decoded_size = &scratch;
+ *decoded_size = 0;
switch (vt) { case VT_I1:
Thank Stefan / Marcus / Andre. This fixed 6 files. 7th file is libdinput.a, which also has some random stuff inside. This was for 32bit chroot. In 64bit chroot these 6 files are also fixed now. libdinput.a differs again. But 64bit chroot also shows 2 other files: * /bin/wmc * /lib64/wine/msi.dll.so These last two differs in Build-id's SHA1 of the .note.gnu.build-id section. Debian Stretch 9.0 Multiarch: * gcc (Debian 6.3.0-6) 6.3.0 20170205 * binutils 2.27.90.20170124-2 * flex 2.6.1-1.3 * bison 3.0.4.dfsg-1 Regards, W.
On Mon, Feb 20, 2017 at 02:27:35AM +0100, wylda(a)volny.cz wrote:
Od: André Hentschel <nerv(a)dawncrow.de>
> Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> value and use that consistently. Why are these libraries built >> inconsitently? Is that intentional? An example is attached.
Thanks. These "random" value come from:
* olepro_t.res * std_ole_v2_t.res * wuapi_tlb_t.res
When i do:
export WIDL_TIME_OVERRIDE="0" rm dlls/olepro32/olepro_t.res make -k dlls/olepro32 md5sum -b dlls/olepro32/olepro_t.res
then i always get different MD5 checksum.
Marcus, could you send me your dlls/olepro32/Makefile please? What is your distro?
I tried above for both 32bit and 64bit directories, always gives the same md5 in those.
openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4
I can reproduce the bug with the instructions above Linux Mint 18.1, gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4), binutils 2.26.1, flex 2.6, biso 3.0.4 the first bad value is at offset 269h Which is datatype2 from MSFT_TypeInfoBase
So initializing datatype2 in add_typedef_typeinfo or the following patch fixes the problem for me:
diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 137bb2d..7904e45 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -798,6 +798,7 @@ static int encode_type( if (!alignment) alignment = &scratch; if (!decoded_size) decoded_size = &scratch;
+ *decoded_size = 0;
switch (vt) { case VT_I1:
Thank Stefan / Marcus / Andre. This fixed 6 files. 7th file is libdinput.a, which also has some random stuff inside.
This was for 32bit chroot. In 64bit chroot these 6 files are also fixed now. libdinput.a differs again.
But 64bit chroot also shows 2 other files: * /bin/wmc * /lib64/wine/msi.dll.so
wmc is bison generating slightly different mcy.tab.c I tracked it down to this diff in mcy.tab.c: -/* In a future release of Bison, this section will be replaced - by #include "mcy.tab.h". */ -#ifndef YY_MCY_MCY_TAB_H_INCLUDED -# define YY_MCY_MCY_TAB_H_INCLUDED + This seems to be emitted depending if mcy.tab.h is present or not. It is caused because we (occasionaly) call the same bison command twice. diff -u xx/log log --- xx/log 2017-03-06 08:41:09.974120440 +0100 +++ log 2017-03-06 08:42:02.226119183 +0100 @@ -35,7 +35,6 @@ -Wignored-qualifiers -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 \ -gstrict-dwarf -O2 -fstack-protector -g -Wall -bison -p mcy_ -o mcy.tab.c /home/marcus/projects/wine/tools/wmc/mcy.y gcc -m64 -c -o mcy.tab.o mcy.tab.c -I. -I/home/marcus/projects/wine/tools/wmc -I../../include \ -I/home/marcus/projects/wine/include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wshift-overflow=2 \ Which is caused by these Makefile rules: mcy.tab.h: /home/marcus/projects/wine/tools/wmc/mcy.y $(BISON) -p mcy_ -o mcy.tab.c -d /home/marcus/projects/wine/tools/wmc/mcy.y mcy.tab.c: /home/marcus/projects/wine/tools/wmc/mcy.y mcy.tab.h $(BISON) -p mcy_ -o $@ /home/marcus/projects/wine/tools/wmc/mcy.y The same bison call will generate both mcy.tab.h and mcy.tab.c, but the rules race each other due to the timestamp of mcy.tab.h being too close to mcy.tab.c. A rule like: mcy.tab.h mcy.tab.c: /home/marcus/projects/wine/tools/wmc/mcy.y $(BISON) -p mcy_ -o mcy.tab.c -d /home/marcus/projects/wine/tools/wmc/mcy.y will also work. I will be sending a patch. Ciao, Marcus
Marcus Meissner <marcus(a)jet.franken.de> writes:
Which is caused by these Makefile rules:
mcy.tab.h: /home/marcus/projects/wine/tools/wmc/mcy.y $(BISON) -p mcy_ -o mcy.tab.c -d /home/marcus/projects/wine/tools/wmc/mcy.y mcy.tab.c: /home/marcus/projects/wine/tools/wmc/mcy.y mcy.tab.h $(BISON) -p mcy_ -o $@ /home/marcus/projects/wine/tools/wmc/mcy.y
The same bison call will generate both mcy.tab.h and mcy.tab.c, but the rules race each other due to the timestamp of mcy.tab.h being too close to mcy.tab.c.
A rule like:
mcy.tab.h mcy.tab.c: /home/marcus/projects/wine/tools/wmc/mcy.y $(BISON) -p mcy_ -o mcy.tab.c -d /home/marcus/projects/wine/tools/wmc/mcy.y
will also work. I will be sending a patch.
No, that doesn't work because both commands can run at the same time and overwrite each other files. That's why the .tab.c needs a dependency on the .tab.h. -- Alexandre Julliard julliard(a)winehq.org
I have changed it to emit only one bison call though... for both files. Does that work? Ciao, Marcus Am 6. März 2017 16:44:50 MEZ schrieb Alexandre Julliard <julliard(a)winehq.org>:
Marcus Meissner <marcus(a)jet.franken.de> writes:
Which is caused by these Makefile rules:
mcy.tab.h: /home/marcus/projects/wine/tools/wmc/mcy.y $(BISON) -p mcy_ -o mcy.tab.c -d /home/marcus/projects/wine/tools/wmc/mcy.y mcy.tab.c: /home/marcus/projects/wine/tools/wmc/mcy.y mcy.tab.h $(BISON) -p mcy_ -o $@ /home/marcus/projects/wine/tools/wmc/mcy.y
The same bison call will generate both mcy.tab.h and mcy.tab.c, but the rules race each other due to the timestamp of mcy.tab.h being too close to mcy.tab.c.
A rule like:
mcy.tab.h mcy.tab.c: /home/marcus/projects/wine/tools/wmc/mcy.y $(BISON) -p mcy_ -o mcy.tab.c -d /home/marcus/projects/wine/tools/wmc/mcy.y
will also work. I will be sending a patch.
No, that doesn't work because both commands can run at the same time and overwrite each other files. That's why the .tab.c needs a dependency on the .tab.h.
-- Alexandre Julliard julliard(a)winehq.org
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Marcus Meissner <marcus(a)jet.franken.de> writes:
I have changed it to emit only one bison call though... for both files.
Does that work?
No, that's not how make works. If there are two targets the command will be run twice. -- Alexandre Julliard julliard(a)winehq.org
On Mon, Mar 06, 2017 at 07:51:18PM +0100, Alexandre Julliard wrote:
Marcus Meissner <marcus(a)jet.franken.de> writes:
I have changed it to emit only one bison call though... for both files.
Does that work?
No, that's not how make works. If there are two targets the command will be run twice.
Hmm, yes. And touching xxxx.tab.c to ensure better ordering ... hmm :/ Ciao, Marcus
participants (3)
-
Alexandre Julliard -
Marcus Meissner -
wylda＠volny.cz