Reproducible builds

[André Hentschel]

Am 19.02.2017 um 22:32 schrieb Marcus Meissner:
> On Sun, Feb 19, 2017 at 07:46:43PM +0100, wylda at volny.cz wrote:
>>> Od: Marcus Meissner <marcus at jet.franken.de>
>>>
>>> CC: <stefandoesinger at gmail.com, wine-devel at winehq.org>
>>> On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda at volny.cz wrote:
>>>>> Od: Stefan Dösinger <stefandoesinger at gmail.com>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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: