Re: Reproducible builds

[André Hentschel]

Am 19.02.2017 um 22:32 schrieb Marcus Meissner:
> On Sun, Feb 19, 2017 at 07:46:43PM +0100, [e-mail] wrote:
> > > Od: Marcus Meissner
> > >
> > > CC: <[e-mail], [e-mail]>
> > > On Sun, Feb 19, 2017 at 05:36:30PM +0100, [e-mail] wrote:
> > > > > Od: Stefan Dösinger
> > > > >
> > > > > Am 2017-02-19 um 10:00 schrieb [e-mail]:
> > > > > > 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.
> > > > >
> > > > > Have you looked at the .o files of those libraries? Finding the .c file
> > > > > that introduces the difference might give some hints to pin down the
> > > > > problem.
> > > >
> > > > Thanks. These "random" value come from:
> > > > - olepro_t.res
> > > > - std_ole_v2_t.res
> > > > - wuapi_tlb_t.res
> > > >
> > > > Anyway, all the other folders also have *.res files. Can these 3 be "fixed"
> > > > so that they behave like the rest of dll-folders? Or can i pass some kind
> > > > of parameter or switch?
> > >
> > > std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds
> > > when I set WIDL_TIME_OVERRIDE="0".
> > >
> > > Same for olepro_t.res
> > >
> > > (current git state)
> >
> > 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.
>
> 64bit:
> 0235f984f3f9f4c781e4e92e5ae7299f *dlls/olepro32/olepro_t.res
> 32bit:
> 106679b36afba236fc28484e69f672f7 *dlls/olepro32/olepro_t.res
>
> openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4
>
> Your debug diff showed a single value fluctuating in multiple places, but its not clear which offset this
> was at. It could be either uninitialized memory or some hash value or so.
> valgrind showing anything?
>
> Ciao, Marcus

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: