wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole
The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so.
I would be happy to supply more details if there is any difficulty replicating this reversion.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" irwin@beluga.phys.uvic.ca wrote:
The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so.
I would be happy to supply more details if there is any difficulty replicating this reversion.
Alan
Please run a regression test and file a bug at http://bugs.winehq.org.
On 2012-12-23 21:25-0600 Austin English wrote:
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" irwin@beluga.phys.uvic.ca wrote:
The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so.
I would be happy to supply more details if there is any difficulty replicating this reversion.
Alan
Please run a regression test and file a bug at http://bugs.winehq.org.
No thank you.
The last time I wrote a wine bug report (with a test case and a patch to fix the problem no less), wine developers seemed content with the fact that that bug had been reported. They did not actually fix the problem until I made a special personal appeal to one of them more than a year later. So eventually there was a happy ending there, but the impression I got from that experience is that Wine bug reports for even the most obvious issues like that one are pretty much a waste of everyone's time unless and until a Wine developer takes responsibility. Of course, in that case the bug reporting system is worthwhile since it can make a permanent record of all the events leading to a solution.
In this case, I would like a Wine developer to take responsibility as well for what I think is an obvious issue with 1.5.20 by verifying the issue, and then taking any further development steps they want to take concerning this issue. Or perhaps there will be an even more obvious symptom of the problem with 1.5.20 that will lead to a solution quicker than if someone follows the MinGW segfault symptom that I have found. In other words, I am willing to help out Wine by reporting the issue informally here, and let Wine developers make their best judgement of what to do about the issue, but that is about it.
Sorry I have to be ruthless about this, but I do not want to get involved in wine development or go through a bunch of Wine bug-reporting hoops since I need to reserve my development efforts for my own free software projects.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2012-12-23 21:25-0600 Austin English wrote:
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" irwin@beluga.phys.uvic.ca wrote:
The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so.
I would be happy to supply more details if there is any difficulty replicating this reversion.
Alan
Please run a regression test and file a bug at http://bugs.winehq.org.
No thank you.
Why would anyone help you if you fail to do your homework? Your bug description is rather vague and you can't expect people to start randomly testing apps until they (supposedly) find the bug you're talking about. Please provide a minimal "simple test program" If you want it fixed, failing to cooperate here won't help you much. Instead, create your test program, specify download links, and describe a minimal procedure to reproduce your bug (and add the appropriate keywords: download, patch, testcase, ...)
http://wiki.winehq.org/BugReports and http://bugs.winehq.org/describekeywords.cgi can help here.
For regressions, especially a rather recent one like you seem to suggest, there are more likely to be fixed quickly, especially if you perform the regression test yourself (reasons: you're in the best position to do it yourself; it can take some time developpers won't necessarily have: if they ran regression tests all day, when would they code???) See http://wiki.winehq.org/RegressionTesting
The last time I wrote a wine bug report (with a test case and a patch to fix the problem no less),
Which bug?
wine developers seemed content with the fact that that bug had been reported. They did not actually fix the problem until I made a special personal appeal to one of them more than a year later. So eventually there was a happy ending there, but the impression I got from that experience is that Wine bug reports for even the most obvious issues like that one are pretty much a waste of everyone's time unless and until a Wine developer takes responsibility. Of course, in that case the bug reporting system is worthwhile since it can make a permanent record of all the events leading to a solution.
If the bug was trivial to fix, why did you not send it yourself to wine-patches? There are a lot of bugs, and not many people who can fix those, so you can't expect *your* bug to be fixed in minutes. If you want to increase your chance for the bug to be fixed, you could wait less than a year, and e.g. restest if the bug still persists every couple of months (or better, after every wine release) and tell so on the bug report.
No amount of complaining on this list will likely help...
In this case, I would like a Wine developer to take responsibility as well for what I think is an obvious issue with 1.5.20 by verifying the issue, and then taking any further development steps they want to take concerning this issue. Or perhaps there will be an even more obvious symptom of the problem with 1.5.20 that will lead to a solution quicker than if someone follows the MinGW segfault symptom that I have found. In other words, I am willing to help out Wine by reporting the issue informally here, and let Wine developers make their best judgement of what to do about the issue, but that is about it.
Again, the bugzilla system is there to report bug, not this mailing list. Do you really expect someone to read your mail and create a bug from it???
Sorry I have to be ruthless about this, but I do not want to get involved in wine development or go through a bunch of Wine bug-reporting hoops since I need to reserve my development efforts for my own free software projects.
If you don't want to be cooperative, why should we help you??? Creating a good bug report is not really "being involved in wine development" IMO. Mere users without any programming experience do it regularly.
Alan
Frédéric
On 2012-12-28 10:44+0100 Frédéric Delanoy wrote:
On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2012-12-23 21:25-0600 Austin English wrote:
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" irwin@beluga.phys.uvic.ca wrote:
The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so.
I would be happy to supply more details if there is any difficulty replicating this reversion.
Alan
Please run a regression test and file a bug at http://bugs.winehq.org.
No thank you.
Why would anyone help you if you fail to do your homework?
The shoe is on the other foot. I am trying to help Wine developers assuming they have an interest in fixing obvious problems in their code no matter how informally such problems are pointed out.
This bug should be easy to replicate. Try to compile any C programme (e.g., a "Hello, world" programme) with MinGW-4.7.0 under wine-1.5.20 and that compiler segfaults. Do the same under wine-1.5.19, and there is no such problem. That's all that should be required to not only replicate the bug but also demonstrate the reversion. Meanwhile, I am happy to stick with 1.5.19 until some Wine developer takes responsibility for getting this regression fixed.
If anybody tries such a test, and doesn't see the issue, then as I said before I am willing to supply more details.
By the way, informal bug reports reported on mailing lists have been quite helpful to me in the past for my own software projects. I also have seen a number of projects spend an inordinate amount of time with bug triage rather than actually fixing the code. So I welcome informal bug reports for my own projects especially when an issue is easy to replicate. It appears you do not personally welcome such informal reports, but hopefully other wine developers are not so inflexible for obvious problems like this one is.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On Fri, Dec 28, 2012 at 11:54 AM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2012-12-28 10:44+0100 Frédéric Delanoy wrote:
On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2012-12-23 21:25-0600 Austin English wrote:
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" irwin@beluga.phys.uvic.ca wrote:
The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so.
I would be happy to supply more details if there is any difficulty replicating this reversion.
Alan
Please run a regression test and file a bug at http://bugs.winehq.org.
No thank you.
Why would anyone help you if you fail to do your homework?
The shoe is on the other foot. I am trying to help Wine developers assuming they have an interest in fixing obvious problems in their code no matter how informally such problems are pointed out.
This bug should be easy to replicate. Try to compile any C programme (e.g., a "Hello, world" programme) with MinGW-4.7.0 under wine-1.5.20 and that compiler segfaults. Do the same under wine-1.5.19, and there is no such problem. That's all that should be required to not only replicate the bug but also demonstrate the reversion. Meanwhile, I am happy to stick with 1.5.19 until some Wine developer takes responsibility for getting this regression fixed.
I think that creating a bug would have taken less time than writing your emails, and be more helpful on the long run (this thread will be archived like others, and be mostly forgotten, unlike bugs in bugzilla)
If anybody tries such a test, and doesn't see the issue, then as I said before I am willing to supply more details.
By the way, informal bug reports reported on mailing lists have been quite helpful to me in the past for my own software projects. I also have seen a number of projects spend an inordinate amount of time with bug triage rather than actually fixing the code.
Wine is a big project. What applies to a small/medium project doesn't necessarily apply here. If everybody started reporting bugs in emails, that would quickly become unmanageable.
So I welcome informal bug reports for my own projects especially when an issue is easy to replicate. It appears you do not personally welcome such informal reports, but hopefully other wine developers are not so inflexible for obvious problems like this one is.
It's not so much that I don't welcome informal reports (they can be helpful of course), but I didn't like the tone of your inital reply. It sounded to me like: "Have someone fix my bug quickly, but I don't want to waste time reporting it correcty ["go through a bunch of Wine bug-reporting hoops"]... so do all the work yourself".
That isn't a nice way to ask for support IMHO, especially for other people volunteering their time on Wine, and who may also have other projects of their own. Also, you didn't probably pay a cent for your wine version, so don't expect people to prioritize the issues you encounter above all others, which may be equally important. Other users have issues with wine but they don't generally complain as loudly as you did.
Alan
Frédéric
On 2012-12-28 13:45+0100 Frédéric Delanoy wrote:
Other users have issues with wine but they don't generally complain as loudly as you did.
It is possible I was not cautious enough with my tone, but let's leave it like this. Wine-1.5.20 has introduced an obvious regression for an important Windows app (the MinGW gcc compiler for Windows) that has been working for years for prior Wine versions.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On 2012-12-28 10:22-0800 Alan W. Irwin wrote:
[...Let's] leave it like this. Wine-1.5.20 has introduced an obvious regression for an important Windows app (the MinGW gcc compiler for Windows) that has been working for years for prior Wine versions.
Grant communicated to me off list that he was able to replicate the regression for Wine-1.5.20, but he also found (as did Boyd) the regression had (inadvertently?) been solved for a recent wine-git version. Grant's results were for MinGW-4.7.2.
I have just now confirmed for MinGW-4.7.0 that Wine-1.5.20 had the issue, but wine-1.5.20-104-g0004788 (or one of the 103 commits before that) solves it. So although using the Wine platform to build software doesn't work for Wine-1.5.20, building and testing software (notably shapelib, PLplot, ephcom, and te_gen using cmake.exe/MinGW/MSYS) works well for 1.5.19, and from my simple test of gcc for recent Wine git, it is certainly looking good for the next Wine release as well!
Grant also told me that gcc had no obvious issues for wine-1.5.20 when invoked directly with wine. Instead he had to follow my wineconsole + bash method for invoking gcc to confirm the issue for wine-1.5.20.
The following is my recipe for that gcc invocation method if anyone here wants to bisect to find the commit between 1.5.19 and 1.5.20 that created the issue, and the commit between 1.5.20 and wine-1.5.20-104-g0004788 that solved it:
(1) Download and install a recent MinGW/MSYS using the automatic installer, mingw-get-inst-20120426.exe that is accessible at https://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-.... Check the GUI box to get the latest versions. Some time ago I installed 4.7.0 this way, and Grant's experience is that now installs 4.7.2. Include MSYS in the install, and install to a unique prefix (rather than a wine system file location). (I did that to make sure I could easily change between wine versions using different PATH and WINEPREFIX values.)
(2) Make a bash "source" script to set up the PATH so that wine can find MinGW and MSYS where you installed them in the above step. Here is my version of that script:
irwin@raven> cat set_mingw_msys_path.wine_sh export MINGW_VERSION=4.7.0 MINGW_PREFIX=/z/home/wine/newstart/MinGW_$MINGW_VERSION PATH=$MINGW_PREFIX/msys/1.0/bin/:$PATH PATH=$MINGW_PREFIX/bin/:$PATH
(3) Get into a wineconsole environment
wineserver -p wineconsole --backend=curses MinGW_4.7.0/msys/1.0/bin/bash.exe
(4) Attempt to compile a "hello-world" programme from that environment
bash.exe-3.1$ source set_mingw_msys_path.wine_sh bash.exe-3.1$ gcc hello_world.c
On wine-1.5.20, this immediately creates an GUI error box. When you exit from that error box, a very long error message is displayed in the wineconsole terminal. In contrast to this bad behaviour of gcc on wine-1.5.20, for both wine-1.5.19 and wine-1.5.20-104-g0004788 this simple test compilation succeeds without issues and you can then run the resulting executable with
bash.exe-3.1$ ./a.exe Hello World
And now back to getting my forthcoming releases of ephcom and te_gen out the door this next weekend.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
-
Alan W. Irwin -
Austin English -
Frédéric Delanoy