before submitting this as bug, some advice please... on slackware 10.2 (gcc 3.3.6) i compile wine cvs, and it has worked so far. last version working is around or exactly 0.9. now, it compiles/installs fine, but any program, including starting just "wine", "notepad" or anything else, ends up quickly with "Segmentation fault". this is my simple custom buildscript...
PKGDATE=`date +%Y%m%d` && CHOST="i686-pc-linux-gnu" \ CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse -mmmx" \ CXXFLAGS=$CFLAGS \ ./configure \ --disable-debug && \ make && make depend && \ checkinstall -S --pkgname=wine --pkgarch=athlonxp --pkgversion=$PKGDATE -y also, tried removing ~/.wine and creating new one, it starts automatic configure but compiled wine also segfaults.
then, changed processor optimizations to much more conservative "-O2 -march=i486 -mcpu=i686" and it it works like a charm. athlon-xp optimizatins used in the first place are from http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
"zhilla" zhilla@spymac.com wrote:
then, changed processor optimizations to much more conservative "-O2 -march=i486 -mcpu=i686" and it it works like a charm. athlon-xp optimizatins used in the first place are from http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
When somebody plays with compiler flags it's definitely wrong. If you are brave enough to use custom compiler switches you are must be qualified enough to cope with any problems caused by that. Feel free to debug it on your own. It's most likely that -fomit-frame-pointer is the culprit.
zhilla wrote:
http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
This is the wrong type of question for wine-devel, and better asked in Gentoo forums or wine-users.
Mike
Mike McCormack wrote:
http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
This is the wrong type of question for wine-devel, and better asked in Gentoo forums or wine-users.
why it is wrong? developers are much more likely to know about compiler flags than users, and gentooers probably use much more bleeding edge version of gcc anyway (slack uses 3.3.6) thanks dmitry for the tip, ill do some further testing. and yeah, i forgot to mention those flags work great for any program i _ever_ tried to compile myself.
zhilla wrote:
why it is wrong? developers are much more likely to know about compiler flags than users, and gentooers probably use much more bleeding edge version of gcc anyway
The way developers recommend compiling Wine is explained in the README file. If you want our help, please try our recommendation first.
Mike
Mike McCormack schrieb:
zhilla wrote:
http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
This is the wrong type of question for wine-devel, and better asked in Gentoo forums or wine-users.
heh? why should that be discussed in gentoo forums?
And it's not like -fomit-frame-pointer is such a high-risky optimization flag. Instead it is in general safe to use for 90% of applications out there( it basicly only prevents that you get some useful debug traces, by saving a few instructions) And like already stated, it used to work in wine too. Until some days ago. So why shouldn't that reported here?
Just for the record: I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer. I will try to find out which patch has caused this.
Peter Beutner wrote:
And it's not like -fomit-frame-pointer is such a high-risky optimization flag. Instead it is in general safe to use for 90% of applications out there
If it fails for 10% of applications out there, then it's *not* safe!
(it basicly only prevents that you get some useful debug traces, by saving a few instructions)
I think turning off the debugging features of Wine isn't such a great idea, and not something that should be encouraged. The more people that do that, the more useless crash reports Wine developers will get.
And like already stated, it used to work in wine too. Until some days ago. So why shouldn't that reported here?
If somebody wants to report that an unsupported flag makes Wine not work, then he should figure out the exact patch and flag combination that caused the regression, and that's the information that should be posted to WineHQ.
Just for the record: I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer. I will try to find out which patch has caused this.
That would be a great idea.
Mike
Mike McCormack schrieb:
Peter Beutner wrote:
And it's not like -fomit-frame-pointer is such a high-risky optimization flag. Instead it is in general safe to use for 90% of applications out there
If it fails for 10% of applications out there, then it's *not* safe!
The question is how often it only exposes a bug in the application(like in this case). ;)
(it basicly only prevents that you get some useful debug traces, by saving a few instructions)
I think turning off the debugging features of Wine isn't such a great idea, and not something that should be encouraged. The more people that do that, the more useless crash reports Wine developers will get.
On the other hand the possibility to optimize wine isn't that bad either. So just tell the users to send only crash reports from builds with debugging infos enabled.;)
And like already stated, it used to work in wine too. Until some days ago. So why shouldn't that reported here?
If somebody wants to report that an unsupported flag makes Wine not work, then he should figure out the exact patch and flag combination that caused the regression, and that's the information that should be posted to WineHQ.
then why not tell him that? Besides there is nowhere stated that there are only certain supported compiler flags which you should use.
Just for the record: I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer. I will try to find out which patch has caused this.
That would be a great idea.
Somebody was faster, there was just sent a patch which fixes the problem. http://www.winehq.org/pipermail/wine-patches/2005-November/021883.html
Mike
Peter Beutner wrote:
Besides there is nowhere stated that there are only certain supported compiler flags which you should use.
Correct. Using any compiler flags other than what configure adds by default is unsupported, untested and unreliable. Even seemingly harmless flags such as "-Wall" cause trouble.
Mike
On Sun, Nov 06, 2005 at 11:39:44PM +0100, Peter Beutner wrote:
Mike McCormack schrieb:
zhilla wrote:
http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
This is the wrong type of question for wine-devel, and better asked in Gentoo forums or wine-users.
heh? why should that be discussed in gentoo forums?
And it's not like -fomit-frame-pointer is such a high-risky optimization flag. Instead it is in general safe to use for 90% of applications out there( it basicly only prevents that you get some useful debug traces, by saving a few instructions) And like already stated, it used to work in wine too. Until some days ago. So why shouldn't that reported here?
Just for the record: I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer. I will try to find out which patch has caused this.
The problem could be a patch, or it could be something else.
While -fomit-frame-pointer is a no-risk option in other programs, this is not the case for WINE.
Why?
Because we call binary code.
And occasionaly this code assumes values in the %ebp register. The best example is EXC_CallHandler() for instance, where windows code looks at the %ebp framechain.
One reason while it is implemented in assembler now.
So please try current CVS after Robs last patch has been applied.
Ciao, Marcus
On Sun, 06 Nov 2005 05:29:02 +0100, zhilla zhilla@spymac.com wrote:
before submitting this as bug, some advice please... on slackware 10.2 (gcc 3.3.6) i compile wine cvs, and it has worked so far. last version working is around or exactly 0.9. now, it compiles/installs fine, but any program, including starting just "wine", "notepad" or anything else, ends up quickly with "Segmentation fault". this is my simple custom buildscript...
PKGDATE=`date +%Y%m%d` && CHOST="i686-pc-linux-gnu" \ CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse -mmmx" \ CXXFLAGS=$CFLAGS \ ./configure \ --disable-debug && \ make && make depend && \ checkinstall -S --pkgname=wine --pkgarch=athlonxp --pkgversion=$PKGDATE -y also, tried removing ~/.wine and creating new one, it starts automatic configure but compiled wine also segfaults.
then, changed processor optimizations to much more conservative "-O2 -march=i486 -mcpu=i686" and it it works like a charm. athlon-xp optimizatins used in the first place are from http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
well if you have to pretend your Athlon-xp is a 486 to get wine to work I would say there's a problem that needs looking at but you probably should pin it down a bit more precisely before reporting it.
you should also look at gcc doc to see what all these things mean before playing with them. Your post indicates you dont know much about CFLAGS apart from what someone added to a wiki page, although I would say those recommendations (rather than what you posted) have been very good for me on Gentoo with Athlon-xp for a couple of years.
I have not tried winecvs since 0.9
HTH
On Sun, 06 Nov 2005 19:11:26 +0100, wino@piments.com wrote:
On Sun, 06 Nov 2005 05:29:02 +0100, zhilla zhilla@spymac.com wrote:
before submitting this as bug, some advice please...
well if you have to pretend your Athlon-xp is a 486 to get wine to work I would say there's a problem that needs looking at but you probably should pin it down a bit more precisely before reporting it.
you should also look at gcc doc to see what all these things mean before playing with them. Your post indicates you dont know much about CFLAGS apart from what someone added to a wiki page, although I would say those recommendations (rather than what you posted) have been very good for me on Gentoo with Athlon-xp for a couple of years.
I have not tried winecvs since 0.9
HTH
Re.
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse
-mmmx" \
You asked for advice, I wont say RTFM, I'll just quote it:
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/i386-and-x86-64-Options.html#i38...
-mtune=cpu-type Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are: ..... athlon-4, athlon-xp, athlon-mp Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE instruction set support. ..... -march=cpu-type Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.
-mcpu=cpu-type A deprecated synonym for -mtune.
Please dont compound the idea that all Gentoo users are cflag-psycopaths. ;)
On Sun, Nov 06, 2005 at 05:29:02AM +0100, zhilla wrote:
before submitting this as bug, some advice please... on slackware 10.2 (gcc 3.3.6) i compile wine cvs, and it has worked so far. last version working is around or exactly 0.9. now, it compiles/installs fine, but any program, including starting just "wine", "notepad" or anything else, ends up quickly with "Segmentation fault". this is my simple custom buildscript...
i can confirm this. i use -mtune=athlon-tbird but somewhere after between 20050930 and CVS-current this "error" slipped into wine. i can not easily test against the patch, that did this to wine. so far the funny thing i came around: WINEDEBUG=+all wine and everything works.
i tried gdb wine-pthread. and it seems to crash somewhere in the locale detection - but the stack is smashed there allready. i will try the "trick" with the non-athlon cflags also on my end and report back.
oh well and btw: gcc 4.0.2.pre (or so) is my compiler.
PKGDATE=`date +%Y%m%d` && CHOST="i686-pc-linux-gnu" \ CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse -mmmx" \ CXXFLAGS=$CFLAGS \ ./configure \ --disable-debug && \ make && make depend && \ checkinstall -S --pkgname=wine --pkgarch=athlonxp --pkgversion=$PKGDATE -y also, tried removing ~/.wine and creating new one, it starts automatic configure but compiled wine also segfaults.
then, changed processor optimizations to much more conservative "-O2 -march=i486 -mcpu=i686" and it it works like a charm. athlon-xp optimizatins used in the first place are from http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are safe cflags, and it worked until couple days ago, then something is definetly wrong, right?
On Mon, 07 Nov 2005 10:25:17 +0100, Christoph Frick frick@sc-networks.de wrote:
oh well and btw: gcc 4.0.2.pre (or so) is my compiler.
come on fellas! now you're using unstable , pre-release compilers.
please dont waste time here. There enough true disfunctionality in Wine that needs to be tracked down and corrected without deliberately trying to break things.
On Mon, Nov 07, 2005 at 12:31:37PM +0100, wino@piments.com wrote:
oh well and btw: gcc 4.0.2.pre (or so) is my compiler.
come on fellas! now you're using unstable , pre-release compilers. please dont waste time here. There enough true disfunctionality in Wine that needs to be tracked down and corrected without deliberately trying to break things.
sorry this compiler came with the distribution - i have no other choice. i also have the impression, that its quite common to linux distributions to use the latest alpha-code to impress the with the high version numbers on the box.
i used various gcc versions over the last years but always used the same compiler flags - never had any problems until last week after the 0.9 release. if -fomit-frame-ponters is the culprit and wine will from now on never ever work with this setting, then add a error to the configure or warn-and-remove from the CFLAGS; but if the resulting code from the same compiler works fine with 20050830 and 20050920 and even with post-09-cvs when using WINEDEBUG=+all, then something is fishy in wine and at least its good to talk about it... and prevent this in the future. obviously also others had the problem with "released" compilers.
On Mon, 07 Nov 2005 14:17:13 +0100, Christoph Frick frick@sc-networks.de wrote:
something is fishy in wine and at least its good to talk about it... and prevent this in the future.
quite so, I think this got sorted pretty quickly by Rob so the patch should get into cvs to solve the anomoly.
i also have the impression, that its quite common to linux distributions to use the latest alpha-code to impress the with the high version numbers on the box.
well I dont know who works like that but they'd better make sure whatever is one the box works once installed since no-one will remain impressed for long and there's a world of choice now.
BTW what distro are you using?
-
Christoph Frick -
Dmitry Timoshkov -
Marcus Meissner -
Mike McCormack -
Peter Beutner -
wino＠piments.com -
zhilla