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