Compilation failure in wine-1.1.44

Hi guys, i can't compile wine-1.1.44 (1.1.43 is OK here like all the
ones before)... As i guess you would not release a wine, which can't
be compiled, than i suspect there could be a trouble in my system (Debian
Lenny 32bit). For this reason, i did not bother to fill a bug ;) as
it would be marked invalid...

Any suggestion? I wanted to give some bugs a retest, but i'm stuck ;)

...
make[2]: Leaving directory `/home/pavel/install/wine/src/wine-1.1.44/tools'

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
-O0  -o config.o ./config.c -DBINDIR='"/usr/local/bin"' -DDLLDIR='"/usr/local/lib/wine"'
-DLIB_TO_BINDIR=\"`../../tools/relpath /usr/local/lib /usr/local/bin`\"
-DLIB_TO_DLLDIR=\"`../../tools/relpath /usr/local/lib /usr/local/lib/wine`\"
-DBIN_TO_DLLDIR=\"`../../tools/relpath /usr/local/bin /usr/local/lib/wine`\"
-DBIN_TO_DATADIR=\"`../../tools/relpath /usr/local/bin /usr/local/share/wine`\"

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
-O0  -o cptable.o cptable.c

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
-O0  -o debug.o debug.c

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
-O0  -o fold.o fold.c

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
-O0  -o ldt.o ldt.c
{standard input}: Assembler messages:
{standard input}:1472: Error: symbol `wine_get_fs' is already defined
{standard input}:1502: Error: symbol `wine_set_fs' is already defined
make[1]: *** [ldt.o] Error 1
make[1]: Leaving directory `/home/pavel/install/wine/src/wine-1.1.44/libs/wine'
make: *** [libs/wine] Error 2

[Roderick Colenbrander]

Yeah the -O0 bug was reported on #winehackers yesterday and will
likely be fixed soon. Compiling using -O2 (which is what you should
use by default anyway unless you have very good reasons not to) should
work fine.

Roderick

On Sat, May 8, 2010 at 2:33 PM,  <wylda(a)volny.cz> wrote:
> Hi guys, i can't compile wine-1.1.44 (1.1.43 is OK here like all the
> ones before)... As i guess you would not release a wine, which can't
> be compiled, than i suspect there could be a trouble in my system (Debian
> Lenny 32bit). For this reason, i did not bother to fill a bug ;) as
> it would be marked invalid...
>
> Any suggestion? I wanted to give some bugs a retest, but i'm stuck ;)
>
> ...
> make[2]: Leaving directory `/home/pavel/install/wine/src/wine-1.1.44/tools'
>
> gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
> -O0  -o config.o ./config.c -DBINDIR='"/usr/local/bin"' -DDLLDIR='"/usr/local/lib/wine"'
> -DLIB_TO_BINDIR=\"`../../tools/relpath /usr/local/lib /usr/local/bin`\"
> -DLIB_TO_DLLDIR=\"`../../tools/relpath /usr/local/lib /usr/local/lib/wine`\"
> -DBIN_TO_DLLDIR=\"`../../tools/relpath /usr/local/bin /usr/local/lib/wine`\"
> -DBIN_TO_DATADIR=\"`../../tools/relpath /usr/local/bin /usr/local/share/wine`\"
>
> gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
> -O0  -o cptable.o cptable.c
>
> gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
> -O0  -o debug.o debug.c
>
> gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
> -O0  -o fold.o fold.c
>
> gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith  -g
> -O0  -o ldt.o ldt.c
> {standard input}: Assembler messages:
> {standard input}:1472: Error: symbol `wine_get_fs' is already defined
> {standard input}:1502: Error: symbol `wine_set_fs' is already defined
> make[1]: *** [ldt.o] Error 1
> make[1]: Leaving directory `/home/pavel/install/wine/src/wine-1.1.44/libs/wine'
> make: *** [libs/wine] Error 2

> Roderick:
> Yeah the -O0 bug was reported on #winehackers yesterday
> and will likely be fixed soon.

Ah, ok :) I know you already test nearly everythink, but what about adding
another test -O{0,1,2,s,...}
a] before official release or
b] evening wine git update
> Compiling using -O2 (which is what you should use by default anyway
> > unless you have very good reasons not to) should work fine.

I quickly thing of these reasons why -O0
* better backtraces for bug reports
* faster compilation during bisection
* recommended for Valgrind
* my brain makes best optimalization, no need for buggy gcc :-D

[Marcus Meissner]

On Sat, May 08, 2010 at 03:02:48PM +0200, wylda(a)volny.cz wrote:
> > Roderick:
> > Yeah the -O0 bug was reported on #winehackers yesterday
> > and will likely be fixed soon.
>
> Ah, ok :) I know you already test nearly everythink, but what about adding
> another test -O{0,1,2,s,...}
> a] before official release or
> b] evening wine git update
> > Compiling using -O2 (which is what you should use by default anyway
> > > unless you have very good reasons not to) should work fine.
>
> I quickly thing of these reasons why -O0
> * better backtraces for bug reports

-O2 works like a charm there too, at least for me.
> * faster compilation during bisection
> * recommended for Valgrind

-O2 works like a charm there too.
> * my brain makes best optimalization, no need for buggy gcc :-D

Also:
* Not testing the code under Release conditions.
* Slow code.

Ciao, Marcus

Hi Marcus,
> > * better backtraces for bug reports
>
> -O2 works like a charm there too, at least for me.

I think i read that somewhere and if i understood that correctly, my
conclusion at that time was, that -02 optimizes the code, so it can
"omit some" part of code and replace them by faster alternative. But
the debuging symbols then don't correspond such optimized code... And
even if i usually don't understand those backtraces, i want to provide
them as much readable for developer as possible.
> * Not testing the code under Release conditions.

I guess, that running Word2007 under linux/wine also does not meet release
conditions by Microsoft ;-) Anyway, i hope that if i run Win program
calculating PI on 4 decimal place, both -O0 and -02 will give me 3.1415
> * Slow code.

This line caused all this replay :) Because it does not says "How much".
So i did some benchmarking which maybe some others find useful.

Compilation of 1.1.43 -O0:
* real 1m 58sec

Compilation of 1.1.43 -O2:
* real 3m 29sec

i.e. -02 is 77% slower. So 10 round of regression test (with in-between
make distclean) is slower in case of -02 cca about 15m 10sec. That's
a lot especially if i want to take bug testing seriously.

Quake 3 1600x1200:
-O0: 215.0 FPS
-O2: 220.1 FPS (2% faster)

Quake 3 640x480:
-O0: 548.3 FPS
-O2: 581.0 FPS (6% faster)

As i'm not pro-gamer anymore and the -O2 results aren't convincing i'll
stay at -O0. Of course everyone has different needs and can find -O2
useful.

BTW: In case of game tests, i did at least five tests for each scenario.

[Nikolay Sivov]

On 5/9/2010 00:21, wylda(a)volny.cz wrote:
> Hi Marcus,
> > > * better backtraces for bug reports
> >
> > -O2 works like a charm there too, at least for me.
>
> I think i read that somewhere and if i understood that correctly, my
> conclusion at that time was, that -02 optimizes the code, so it can
> "omit some" part of code and replace them by faster alternative. But
> the debuging symbols then don't correspond such optimized code... And
> even if i usually don't understand those backtraces, i want to provide
> them as much readable for developer as possible.

It's mostly about a parameters printed in backtraces, with -O2 you'll 
see sometimes missed register
values replaced with <register EDI not in topmost frame> for example. 
Don't know about inline things,
probably it could be inlined anyway with -O0 too, but I'm not sure.

[Eric Pouech]

Le 08/05/2010 22:37, Nikolay Sivov a écrit :
> On 5/9/2010 00:21, wylda(a)volny.cz wrote:
> > Hi Marcus,
> > > > * better backtraces for bug reports
> > > > -O2 works like a charm there too, at least for me.
> > > > I think i read that somewhere and if i understood that correctly, my
> > > > conclusion at that time was, that -02 optimizes the code, so it can
> > > > "omit some" part of code and replace them by faster alternative. But
> > > > the debuging symbols then don't correspond such optimized code... And
> > > > even if i usually don't understand those backtraces, i want to provide
> > > > them as much readable for developer as possible.
> > > > It's mostly about a parameters printed in backtraces, with -O2 you'll 
> > > > see sometimes missed register
> > > > values replaced with <register EDI not in topmost frame> for example. 
> > > > Don't know about inline things,
> > > > probably it could be inlined anyway with -O0 too, but I'm not sure.

this behavior is fixed with current git (except if gcc really optimizes 
things out, but wine now behaves as gcc, so you should be way less 
hindered by debugging with -O2 as you were)
A+

-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

[Ben Klein]

On 9 May 2010 06:21,  <wylda(a)volny.cz> wrote:
> Hi Marcus,
> > > * better backtraces for bug reports
> >
> > -O2 works like a charm there too, at least for me.
>
> I think i read that somewhere and if i understood that correctly, my
> conclusion at that time was, that -02 optimizes the code, so it can
> "omit some" part of code and replace them by faster alternative. But
> the debuging symbols then don't correspond such optimized code... And
> even if i usually don't understand those backtraces, i want to provide
> them as much readable for developer as possible.

The debugging symbols do match to the optimised code, and refer you
back to the unoptimised line of source. Any cases where -O0 and -O2
give different results for backtraces are bugs in the gcc optimisation
code, not in Wine.
> > * Not testing the code under Release conditions.
>
> I guess, that running Word2007 under linux/wine also does not meet release
> conditions by Microsoft ;-) Anyway, i hope that if i run Win program
> calculating PI on 4 decimal place, both -O0 and -02 will give me 3.1415

The point is that Wine's code for releases is not compiled with -O0.
We don't want Word2007 bugs on bugs.winehq.org.

GCC's optimisation has nothing to do with accuracy; it's all to do
with speed. Speed of code execution is an issue primarily with latency
and race condition issues and/or bugs.
> > * Slow code.
>
> This line caused all this replay :) Because it does not says "How much".
> So i did some benchmarking which maybe some others find useful.
>
> Compilation of 1.1.43 -O0:
> * real 1m 58sec
>
> Compilation of 1.1.43 -O2:
> * real 3m 29sec
>
> i.e. -02 is 77% slower. So 10 round of regression test (with in-between
> make distclean) is slower in case of -02 cca about 15m 10sec. That's
> a lot especially if i want to take bug testing seriously.

"Slow code" and "slow compilation" are very different concerns.

For regression testing, make distclean is generally a bad idea as it
really does take a long time. Either way, ccache mitigates increases
in time, and -O0 may theoretically produce false positives for bug
testing where the issue is latency or race condition related.
> Quake 3 1600x1200:
> -O0: 215.0 FPS
> -O2: 220.1 FPS (2% faster)
>
> Quake 3 640x480:
> -O0: 548.3 FPS
> -O2: 581.0 FPS (6% faster)
>
> As i'm not pro-gamer anymore and the -O2 results aren't convincing i'll
> stay at -O0. Of course everyone has different needs and can find -O2
> useful.

I don't think Quake 3 counts as number-crunching. I imagine heavy
number-crunching apps would suffer significantly more with -O0.

Ben Klein:
> Any cases where -O0 and -O2 give different results for backtraces are
> > bugs in the gcc optimisation code, not in Wine.

And this was excatly one of the reasons, why use -O0. I do not want to
report gcc bugs in wine's bugzilla.
> Speed of code execution is an issue primarily with latency and race
> > condition issues and/or bugs.

Correct me, if i'm wrong, but these kind of wine bugs aren't "100%",
because they can be influenced by other thing. Can singlecore vs multicore
CPU has any impact for reproducibility??

Anyway, i'm only able to bisect bugs, which are always reproducible the
same way, so i can easily suite that results into bisect good/bad. Anything
beyond causes, that i leave such bug report (i'm mostly interested in
looking for some other's reported regression and their retest).

So as other people are reporting problem (99% ?? with default -02) and
i join such bug report with regression report from -O0, i shouldn't
mess bugzilla with rubbish.
> For regression testing, make distclean is generally
> a bad idea as it really does take a long time.

This is generally not true for example in between 1.1.30~.31 (if i remember
correctly). I was not able to find any game regression this way. I had
always "git bisect bad". Fixed by in between "make distclean".
> Either way, ccache mitigates increases in time, and -O0 may
> theoretically produce false positives for bug testing where the
> issue is latency or race condition related.

As i wrote above, i would probably avoid such bug report retest. And
also compare this (rare??) case with number of FP in bugzilla (all those
marked as INVALID, etc.). Hopefully bugzilla state is not getting worse
with my -O0 ;-)
> I don't think Quake 3 counts as number-crunching. I imagine heavy
> number-crunching apps would suffer significantly more with -O0.

Agree.

[Francois Gouget]

On Sat, 8 May 2010, wylda(a)volny.cz wrote:
[...]
> > * Not testing the code under Release conditions.
>
> I guess, that running Word2007 under linux/wine also does not meet release
> conditions by Microsoft ;-) Anyway, i hope that if i run Win program
> calculating PI on 4 decimal place, both -O0 and -02 will give me 3.1415

It would be better if both gave 3.1416...


-- 
Francois Gouget <fgouget(a)free.fr>              http://fgouget.free.fr/
                     Avoid the Gates of Hell - use Linux.