20 Feb
2017
20 Feb
'17
1:27 a.m.
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? 
6 Mar
6 Mar
8 a.m.
New subject: Reproducible builds
On Mon, Feb 20, 2017 at 02:27:35AM +0100, wylda(a)volny.cz wrote:
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
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
3:44 p.m.
New subject: Reproducible builds
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
4:42 p.m.
New subject: Reproducible builds
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>rg>:
Marcus Meissner <marcus(a)jet.franken.de> writes:
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
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
6:51 p.m.
New subject: Reproducible builds
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
8:47 p.m.
New subject: Reproducible builds
On Mon, Mar 06, 2017 at 07:51:18PM +0100, Alexandre Julliard wrote:
Marcus Meissner <marcus(a)jet.franken.de> writes:
Hmm, yes.
And touching xxxx.tab.c to ensure better ordering ... hmm :/
Ciao, Marcus
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.
2615
days inactive
2629
days old
5 comments
3 participants
participants (3)
-
Alexandre Julliard -
Marcus Meissner -
wylda＠volny.cz