Reproducible builds

[Marcus Meissner]

On Mon, Feb 20, 2017 at 02:27:35AM +0100, wylda at volny.cz wrote:
> > Od: André Hentschel <nerv at dawncrow.de>
> 
> >>>>>> Am 2017-02-19 um 10:00 schrieb wylda at 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