Andrey Turkin has stated at http://bugs.winehq.org/show_bug.cgi?id=24018 that this is really a Cygwin bug. I frankly don't understand the technical details but his current test (an infinite loop with Cygwin fork calls) may need some beefing up to convince the Cygwin developers they have introduced a regression.
The reason why I mention a Cygwin regression is the winetricks script mentions bug 24018 and works around it by downloading an old version of the Cygwin installer. I haven't tried that myself yet, but if that workaround still works, then this is evidence that the issue is a Cygwin regression which is an important consideration when reporting this issue to the Cygwin developers.
Andrey Turkin was asked at http://bugs.winehq.org/show_bug.cgi?id=24018 to report the issue to Cygwin, but my search of the Cygwin mailing list archive didn't find any post from him and only found one extremely casual (an aside to a completely different thread) mention (http://sourceware.org/ml/cygwin/2013-06/msg00471.html) from a different wine developer of bug 24018 with no response to that mention.
I currently have no experience with Cygwin and my only real interest in Cygwin on Wine is it theoretically provides an alternative build platform to my present successful work with the combination of MinGW, MSYS, and Wine as a Windows build platform. But I haven't even been able to get started with Cygwin on Wine because of this showstopping bug. Therefore, I am mentioning the situation here in the hope that some wine developer on this list with some knowledge of Cygwin will take the responsibility of making a proper bug report to the Cygwin mailing list (which according to http://cygwin.com/problems.html is the correct place to report Cygwin bugs) including the evidence that the issue is a Cygwin regression (assuming investigation of older Cygwin versions with Turkin's test supports that conclusion).
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 Tue, 25/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
<snipped>
I currently have no experience with Cygwin and my only real interest in Cygwin on Wine is it theoretically provides an alternative build platform to my present successful work with the combination of MinGW, MSYS, and Wine as a Windows build platform. But I haven't even been able to get started with Cygwin on Wine because of this showstopping bug. Therefore, I am mentioning the situation here in the hope that some wine developer on this list with some knowledge of Cygwin will take the responsibility of making a proper bug report to the Cygwin mailing list (which according to http://cygwin.com/problems.html is the correct place to report Cygwin bugs) including the evidence that the issue is a Cygwin regression (assuming investigation of older Cygwin versions with Turkin's test supports that conclusion).
<snipped>
FWIW, the fact that cygwin's setup has problems working doesn't not stop you from *trying* cygwin - it doesn't do very much more than just unpacking tar.tgz files, which you can do manually. And for many command-line utilities, just have the exe and the dll around is enough.
However, I found that cygwin version of a few utlities does not work correctly uner wine (it obvious does for some under genuine windows). While the mingw/gnuwin32 equivalent, do. echo and cat were two I had problems with, when I accidentally let some 3rd party's installer put cygwin's cat/echo in front of gnuwin32's cat/echo in my $PATH under cmd.
Also, I believe MSYS and Mingw do not depends on cygwin. cygwin and msys/mingw are rather different. For building windows applications, you really want to stick with mingw if you can.
And, I found cross-compiling works well enough that I don't bother with having a mingw-based dev system under wine. And if I need MS VC specifically, that works well under wine so; so there has not been any need for running mingw or cgywin under wine for a while. I can tell you from first hand experience that mingw gcc/g++ works well under wine, but many times slower compared to cross-compiling. I think the speed problem comes from fork/exec being slow in wine.
On 2013-06-26 23:43+0100 Hin-Tak Leung wrote:
--- On Tue, 25/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
<snipped> > I currently have no experience with Cygwin and my only real > interest > in Cygwin on Wine is it theoretically provides an > alternative build > platform to my present successful work with the combination > of MinGW, > MSYS, and Wine as a Windows build platform. But I haven't > even been > able to get started with Cygwin on Wine because of this > showstopping > bug. Therefore, I am mentioning the situation here in the > hope that > some wine developer on this list with some knowledge of > Cygwin will > take the responsibility of making a proper bug report to the > Cygwin > mailing list (which according to http://cygwin.com/problems.html is > the correct place to report Cygwin bugs) including the > evidence that > the issue is a Cygwin regression (assuming investigation of > older Cygwin > versions with Turkin's test supports that conclusion). <snipped>
FWIW, the fact that cygwin's setup has problems working doesn't not stop you from *trying* cygwin - it doesn't do very much more than just unpacking tar.tgz files, which you can do manually. And for many command-line utilities, just have the exe and the dll around is enough.
One of the disadvantages of MinGW/MSYS as a build platform is you pretty much have to build all your own free software libraries to keep ABI/API consistent. However, it is not too bad because I am automating that process with my "build_projects" project.
One of the theoretical advantages of Cygwin as a build platform is access to lots of free libraries that have been built with a consistent "Cygwin" ABI/API. But I would prefer not to implement a replacement for setup.exe that downloads and installs all of those libraries keeping track of all library dependencies. Instead, I would prefer to see bug 24018 fixed so that setup.exe can be used for this task. But that fix will likely require some rather deep knowledge of both Cygwin and Wine.
However, I found that cygwin version of a few utlities does not work correctly uner wine (it obvious does for some under genuine windows). While the mingw/gnuwin32 equivalent, do. echo and cat were two I had problems with, when I accidentally let some 3rd party's installer put cygwin's cat/echo in front of gnuwin32's cat/echo in my $PATH under cmd.
It's entirely possible that some Cygwin apps don't work correctly under Wine, but that probably depends on both Cygwin and Wine versions. Also, when confirming these issues, it would probably be best to use setup.exe for installation since I doubt any Cygwin developer would trust a Cygwin installation created by anything other than setup.exe. So the current broken setup.exe on Wine is a pretty big barrier to discovering, confirming, and fixing other Cygwin on Wine issues.
Also, I believe MSYS and Mingw do not depends on cygwin. cygwin and msys/mingw are rather different. For building windows applications, you really want to stick with mingw if you can.
I agree there are big differences between Cygwin and MinGW/MSYS and the former has some extra baggage as a platform that some Windows developers do not like. But I do not mind extra Cygwin baggage at all assuming Cygwin provides a set of free libraries that has a coherent API/ABI.
And, I found cross-compiling works well enough that I don't bother with having a mingw-based dev system under wine. And if I need MS VC specifically, that works well under wine so; so there has not been any need for running mingw or cgywin under wine for a while. I can tell you from first hand experience that mingw gcc/g++ works well under wine, but many times slower compared to cross-compiling. I think the speed problem comes from fork/exec being slow in wine.
For me an integral part of package building is package testing. Cross-compilation only does the building part while Wine is quite good for providing both a build and test platform. I do agree with you it is slow compared to the Linux equivalent of the same build and test due to application startup latency issues. My experience is the overall slowdowns are from a factor of two to five depending on how much the build and test timing is dominated by small tasks (i.e., whether the build consist of many compilations of small files or a few compilations of large files and whether the individual tests are short or long.) Apparently Cygwin on the Microsoft version of Windows also has similar issues with fork inefficiency. See the discussion in http://cygwin.com/cygwin-ug-net/highlights.html. So I expect these startup latency issues inevitably occur for any shell environment (such as MSYS's bash.exe) that attempts to fork tasks on Windows.
That said, I am happy to accept such build and test slowdowns for MinGW/MSYS or Cygwin on Wine in order to have access to free (in both senses), realistic, and extremely convenient (no dual-booting necessary) Windows build and test platforms. If I ever get inconvenienced by the factors of two to five slowdowns I have seen for typical builds and tests I could always go out and buy a faster computer! :-)
Therefore, for free software developers I view MinGW/MSYS on Wine as a pretty ideal build and test platform. I also plan to start trying Cygwin on Wine as a build and test platform as soon as the Cygwin and Wine developers get together and figure out the best way to fix bug 24018.
Note in retrospect I realized that this period leading up to the release of Wine-1.6.0 has been a lousy time to ask wine developers with Cygwin expertise to take on the additional distraction of getting the debugging process for bug 24018 started with the Cygwin developers. Therefore, if I don't get any further response now, I will ping about this substantially (a few months) later when times presumably won't be so hectic for Wine developers. In any case I am confident this important bug will eventually be solved because there is obviously a lot of interest (just from the "me too's" in the bug report) in running Cygwin on top of Wine.
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 2013-06-26 18:14-0700 Alan W. Irwin wrote:
Note in retrospect I realized that this period leading up to the release of Wine-1.6.0 has been a lousy time to ask wine developers with Cygwin expertise to take on the additional distraction of getting the debugging process for bug 24018 started with the Cygwin developers.
Because of the bad timing from the Wine developer perspective, I asked Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try and get the debugging process started with the Cygwin developers. The response http://cygwin.com/ml/cygwin/2013-06/msg00666.html to his post looks quite promising. It turned out the "fork bomb" test programme failed after only 500 iterations, and the Cygwin developer, Corinna Vinschen thinks she knows what the issue is with more to come. So stay tuned to that thread if you have an interest in bug 24018.
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 2013-06-27 09:39-0700 Alan W. Irwin wrote:
[...]I asked Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try and get the debugging process started with the Cygwin developers. The response http://cygwin.com/ml/cygwin/2013-06/msg00666.html to his post looks quite promising. It turned out the "fork bomb" test programme failed after only 500 iterations, and the Cygwin developer, Corinna Vinschen thinks she knows what the issue is with more to come. So stay tuned to that thread if you have an interest in bug 24018.
The bug has now been fixed to the extent that the fork bomb test now works on Cygwin. However, if you continue following that Cygwin mailing list thread you will see I have had absolutely no luck with running Cygwin's setup.exe under Wine (for Wine-1.5.19 and Wine-git near 1.6-rc1 which are both versions I have heavily tested with my MinGW/MSYS build project). For both wine versions and regardless or not of whether I use a fork-corrected cygwin1.dll or not I am getting a hang in the critical script run at the end of the install by setup.exe rather than the error message I used to get a month ago with wine-1.5.19 when that same script was run. That error message was identical to the other reports at http://bugs.winehq.org/show_bug.cgi?id=24018 but now it has been replaced by a hang thanks (presumably) to either some change in Cygwin in the last month (other than the fork-bomb fix) or me inadvertently running setup.exe incorrectly from Wine.
Anyhow, it is time for some wine developer with some expertise in Cygwin (which I don't have) to evaluate the Cygwin fork-bomb fix and see if it is possible with that fix to run setup.exe without issues on Wine. I presume this is a hectic time for you guys due to the imminent release of 1.6.0. However, because of the Cygwin fork bug, Cygwin on Wine has largely been untested for the last three years so this could be a good opportunity to do such testing for the combination of Cygwin (with the fork fix) and recent Wine in case some Wine regression is discovered by such testing.
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, 28/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
... However, because of the Cygwin fork
bug, Cygwin on Wine has largely been untested for the last three years so this could be a good opportunity to do such testing for the combination of Cygwin (with the fork fix) and recent Wine in case some Wine regression is discovered by such testing.
what????!!!! You really don't get it. setup.exe is simply *not* a necessity for putting a cygwin installation under wine. There are many other ways of installing cygwin into wine without running cygwin's installer. The easiest is simply to copy the entire installed directory, plus importing a few registry entries, from a genuine windows box which has cygwin on.
(There are many people who bundles bits of cygwin with their software for windows, for years; so if you are a full-time windows user, you might even gain some bits of cygwin without knowing it, and without ever having seen the official cygwin installer or even heard of it) . The problem is that even if you manage to put it on, many part of cygwin don't work correctly under wine.
Please don't confuse issues with running the official installer, and issues with running the cygwin system (or part of) itself. You have been told *many times*, in that thread, that setup.exe itself does not depend on cygwin, and use no part of it.
On 2013-06-28 22:37+0100 Hin-Tak Leung wrote:
--- On Fri, 28/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
... However, because of the Cygwin fork
bug, Cygwin on Wine has largely been untested for the last three years so this could be a good opportunity to do such testing for the combination of Cygwin (with the fork fix) and recent Wine in case some Wine regression is discovered by such testing.
what????!!!! You really don't get it.
Yes I do. :-)
Enuf said.
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 2013-06-28 23:37, Hin-Tak Leung wrote:
--- On Fri, 28/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
... However, because of the Cygwin fork
bug, Cygwin on Wine has largely been untested for the last three years so this could be a good opportunity to do such testing for the combination of Cygwin (with the fork fix) and recent Wine in case some Wine regression is discovered by such testing.
what????!!!! You really don't get it. setup.exe is simply *not* a necessity for putting a cygwin installation under wine. There are many other ways of installing cygwin into wine without running cygwin's installer. The easiest is simply to copy the entire installed directory, plus importing a few registry entries, from a genuine windows box which has cygwin on.
(There are many people who bundles bits of cygwin with their software for windows, for years; so if you are a full-time windows user, you might even gain some bits of cygwin without knowing it, and without ever having seen the official cygwin installer or even heard of it) . The problem is that even if you manage to put it on, many part of cygwin don't work correctly under wine.
Please don't confuse issues with running the official installer, and issues with running the cygwin system (or part of) itself. You have been told *many times*, in that thread, that setup.exe itself does not depend on cygwin, and use no part of it.
Running the official installer invokes child processes that do indeed require a functioning Cygwin DLL. I.e. post-install scripts (and pre- remove scripts, but we're talking about the initial install so that's out of scope).
The registry entries you speak about are a thing of the past, if you are referring to mount points.
Cheers, Peter
--- On Thu, 27/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2013-06-26 18:14-0700 Alan W. Irwin wrote:
Note in retrospect I realized that this period leading
up to the
release of Wine-1.6.0 has been a lousy time to ask wine
developers
with Cygwin expertise to take on the additional
distraction of getting
the debugging process for bug 24018 started with the
Cygwin
developers.
Because of the bad timing from the Wine developer perspective, I asked Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try and get the debugging process started with the Cygwin developers. The response http://cygwin.com/ml/cygwin/2013-06/msg00666.html to his post looks quite promising. It turned out the "fork bomb" test programme failed after only 500 iterations, and the Cygwin developer, Corinna Vinschen thinks she knows what the issue is with more to come. So stay tuned to that thread if you have an interest in bug 24018.
I read that thread with interest.
However, I noticed that you have quite a few fundamental misunderstanding or lack of experience with cygwin.
Firstly, cygwin's setup.exe doesn't do much more than unpacking tar balls, write a few registry entries, and run some scripts through sh.exe, occasionally. (the last one depends on the package, the middle one is one-off, the first time ever you run setup.exe - there after it just read those entries back; the unpacking obviously happens per package).
So it is entirely possible to *install* cygwin into a wine prefix, without using cygwin's setup.exe, if you know how to unpack those files as well as set up the registry entries. It is even easier if you have access to a windows box: you can simply export those registries and import them into wine, copy the entire installed tree across from a windows box to wine. That, in principle, gives identical results as if you manage to run the setup.exe . (you can clone a cygwin installation across windows boxes in exactly the same way i.e. by copying the whole installed directory, plus export/importing a few registry entries.).
However, being able to install does not equal to being able to run, or run correctly. I thought I wrote that already. Anyway, *some* people bundle bits of cygwin in their custom software for little things, and I have come across at least one such installer. The installer runs fine with wine, but the installed cygwin bits don't work correctly in wine. cat & echo were the two I noticed - the latter is fairly awful, since cmd has a built in echo, and wine cmd's works alright; said custom software installer also put its binaries in the front of the system $PATH (or if you prefer window's style, %PATH%).
The added registry entries - or at least the important ones - are, if I remember correctly, the mount table i.e. it tells the installed bits where to find /usr/share, etc. Of course some, e.g. again, cat, echo, etc don't really have extra bits to look up, unlike say, emacs - which have lisp code files to load - and cat, echo, etc are supposed to work without cygwin mount table entires. On windows, they do work, and on wine, they don't (*not* because of the absence).
You can try very simple things, like e.g. "cat fileA fileB > fileC", if you need convincing.
On 2013-06-28 22:07+0100 Hin-Tak Leung wrote:
--- On Thu, 27/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
[...]I asked Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try and get the debugging process started with the Cygwin developers. The response http://cygwin.com/ml/cygwin/2013-06/msg00666.html to his post looks quite promising. [and now has arrived at a solution that
solves the fork bomb test].
I read that thread with interest.
However, I noticed that you have quite a few fundamental misunderstanding or lack of experience with cygwin.
Definitely the latter and probably the former. :-)
[....] However, being able to install [by alternative means than
setup.exe] does not equal to being able to run [...]
I absolutely agree, but I am concerned that those alternative installation means might be the source of the issue.
You can try very simple things, like e.g. "cat fileA fileB > fileC", if you need convincing.
Have you reported this to Cygwin as a bug? Their response to the fork issue was extraordinarily fast.
By the way, when you report that possible cat bug to Cygwin, I am sure they will insist you use standard means (e.g., setup.exe) to install Cygwin to remove any uncertainty about whether your non-standard installation is the cause of the issue. And they will also probably insist you demonstrate the issue for the Microsoft version of Windows since Wine currently has an uncertain reputation (rightly or wrongly but we cannot say anything about that until the standard Cygwin method of installation works) concerning its ability to run Cygwin.
You may have really found a valid Cygwin bug for their version of cat. But I _know_ the MSYS version of cat works fine on recent Wine just like the rest of the GNU toolchain used for building software so if the MSYS and Cygwin GNU toolchain code bases have not diverged too much it should be straightforward (and probably quite fast, if the fork bugfix speed is anything to go by) for the Cygwin developers to fix the issue if you prove it actually exists with a standard Cygwin installation on Microsoft Windows.
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, 28/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
... But I _know_ the MSYS version of cat works fine on recent
Wine just like the rest of the GNU toolchain used for building software so if the MSYS and Cygwin GNU toolchain code bases have not diverged too much it should be straightforward (and probably quite fast,
...
Again, MSYS (i.e. Mingw) is not cygwin. This is probably an FAQ on mingw's web site. You really need to do some reading.
The Mingw GNU toolchain works wells under wine. The cygwin GNU toolchain don't, the last time I checked.
On 2013-06-28 23:13+0100 Hin-Tak Leung wrote:
--- On Fri, 28/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
... But I _know_ the MSYS version of cat works fine on recent
Wine just like the rest of the GNU toolchain used for building software so if the MSYS and Cygwin GNU toolchain code bases have not diverged too much it should be straightforward (and probably quite fast,
...
Again, MSYS (i.e. Mingw) is not cygwin. This is probably an FAQ on mingw's web site. You really need to do some reading.
Hmm. I think the shoe is on the other foot. Please read what I said above which clearly acknowledges the well-known differences between the MinGW/MSYS GNU toolchain and the Cygwin one.
The Mingw GNU toolchain works wells under wine. The cygwin GNU toolchain don't, the last time I checked.
That may be true, but the best way to make that point about the Cygwin GNU toolchain is with official Cygwin bug reports rather than asserting stuff here in an anecdotal way.
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 Sat, 29/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
...
The Mingw GNU toolchain works wells under wine. The
cygwin GNU toolchain don't, the last time I checked.
That may be true, but the best way to make that point about the Cygwin GNU toolchain is with official Cygwin bug reports rather than asserting stuff here in an anecdotal way.
No. Anytime that a piece of windows software (including Cygwin) works on windows but not on wine, is a wine problem. The fact that the such software developers (cygwin people) are nice enough to respond and adjust their software (cygwin) to fit a *flaw in wine* does not make the problem less a wine one.
The various problems of running cygwin in wine are already well-documented - just do a search on wine's bugzilla (there are over a dozen of those). So the mere fact that the installer does not work correctly, is just another such problem. Also, running cygwin on wine, compared to other windows software which has no unix/linux equivalents, is hardly a priority.
One bug among many, and on a piece of software which is interesting but not a priority. That's what the issue is.
On 2013-06-29 11:57+0100 Hin-Tak Leung wrote:
--- On Sat, 29/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
...
The Mingw GNU toolchain works wells under wine. The
cygwin GNU toolchain don't, the last time I checked.
That may be true, but the best way to make that point about the Cygwin GNU toolchain is with official Cygwin bug reports rather than asserting stuff here in an anecdotal way.
Anytime that a piece of windows software (including Cygwin) works on windows but not on wine, is a wine problem.
No question. In fact I stated bug reports to Cygwin would probably only be taken seriously if they included a demonstration of the problem on the Microsoft version of Windows.
The fact that the such software developers (cygwin people) are nice enough to respond and adjust their software (cygwin) to fit a *flaw in wine* does not make the problem less a wine one.
This statement misrepresents what has recently occurred with regard to bug 24018. Arjen Markus's bug report demonstrated the Cygwin fork problem on Microsoft Windows. Because of that the Cygwin developers were quickly able to verify and fix the problem.
The various problems of running cygwin in wine are already
well-documented - just do a search on wine's bugzilla (there are over a dozen of those).
Those have been mentioned before here, and I have looked at them. Cygwin is a very large collection of software so the number of bugs that are reported does not seem excessive to me, and for my personal needs (building and testing software on the Cygwin platform) I will only be using a subset of Cygwin so I may avoid encountering some of these bugs. Furthermore, some of these bugs (e.g., problems resizing a GUI) are not showstoppers, and most of them are quite old. At the same time the latest Wine is far superior to Wine-1.4 so some of those bugs may have just disappeared. I hope to find out about the actual status of Cygwin on Wine bugs once I can get setup.exe to work on Wine.
So the mere fact that the installer does not work correctly, is just
another such problem.
That's been covered already. We obviously disagree on this issue.
Also, running cygwin on wine, compared to other windows software
which has no unix/linux equivalents, is hardly a priority.
That is obviously personally true for you. And for my personal needs Cygwin on Wine is a "would be nice" software build and test platform. That is, it is actually a medium to low priority for me since I already have plenty to do extending my builds and tests of free software on the MinGW/MSYS/Wine platform to additional software packages.
But our personal needs are not what is important here. From the more general perspective any problems running open-source software on Wine should be easier to debug (since all the details of the exact Windows system calls are known) than trying to debug problems with running proprietary software (e.g., some random game) on Wine where you have to guess at the details. As an illustration of that, three times during the 1.5.x series I have found Wine bugs or regressions as a result of running open source software on Wine. (Thankfully, all of those have been fixed by the Wine developers.) Cygwin is the largest distribution of open-source software that runs on Windows. It follows that Cygwin represents a good opportunity to find and fix Wine issues.
In sum you have expressed your opinions on Cygwin and Wine and I have mostly disagreed with those opinions. Therefore, I think we have covered everything, and it is time to call a halt to this side-topic. So from now on my contributions to this thread will focus on the original topic which is problems in running setup.exe on Wine, i.e., bug 24018, and I urge you to do the same.
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 Sat, 29/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
...
Also, running cygwin on wine, compared to other windows
software which has no unix/linux equivalents, is hardly a priority.
That is obviously personally true for you. And for my personal needs Cygwin on Wine is a "would be nice" software build and test platform.
...
No. Just the fact that nobody else bothered to respond to this thread should convince you that getting cygwin is not a priority to most people who is knowledgeable and capable of hacking wine.
As for true for me - well, I have fixed or help fixed a few issue of wine with running microsoft products - embedded IE rendering, and Microsoft's development tool chain (yes, I am talking about Visual C++, and nmake, [Microsoft's make], and microsoft's manifest modification tool whose name I forget - the tool for Microsoft's way of modifying executable binaries post-compilation). Obviously my interests lies elsewhere. Mingw works alright. Cygwin is just not a priority for my time, and I sincerely hope that other people who are capable of improving wine would spend their time on more worthwhile causes.
p.s. using words like "showstopper" actually put people off.
On 29.06.2013 23:34, Hin-Tak Leung wrote:
--- On Sat, 29/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
...
Also, running cygwin on wine, compared to other windows
software which has no unix/linux equivalents, is hardly a priority.
That is obviously personally true for you. And for my personal needs Cygwin on Wine is a "would be nice" software build and test platform.
...
No. Just the fact that nobody else bothered to respond to this thread should convince you that getting cygwin is not a priority to most people who is knowledgeable and capable of hacking wine.
I've been following this thread. What i would like to point you all to is: http://wiki.winehq.org/CygwinSupport It describes why running cygwin on wine is not that senseless low priority thing. Further it's mentioned at: http://wiki.winehq.org/TodoList and http://wiki.winehq.org/UnitTestSuites
--- On Sun, 30/6/13, André Hentschel nerv@dawncrow.de wrote:
On 29.06.2013 23:34, Hin-Tak Leung wrote:
--- On Sat, 29/6/13, Alan W. Irwin irwin@beluga.phys.uvic.ca
wrote:
...
Also, running cygwin on wine, compared to other
windows
software which has no unix/linux equivalents, is hardly a
priority.
That is obviously personally true for you.
And for my
personal needs Cygwin on Wine is a "would be nice" software build
and test
platform.
...
No. Just the fact that nobody else bothered to respond
to this thread should convince you that getting cygwin is not a priority to most people who is knowledgeable and capable of hacking wine.
I've been following this thread. What i would like to point you all to is: http://wiki.winehq.org/CygwinSupport It describes why running cygwin on wine is not that senseless low priority thing. Further it's mentioned at: http://wiki.winehq.org/TodoList and http://wiki.winehq.org/UnitTestSuites
Wiki is what it is - anybody with a wish can add an entry. If somebody put their name down and say: "*I* will do this!" - and have the knowledge & incentive to deliver, that's when it gets interesting. Until then, it is not. (Those entries might just have been added by the original poster of this thread - doesn't prove anything).
Using words like "showstopper" is off-putting. Especially considering there are at least two well-known(?) ways of getting around a mere installation problem of a piece of [any] open-source software - (1) unpack manually. It is open-source and all the actions of the installer are known; (2) copy from an existing installation & clone the relevant registry entries.
and (3) being able to install is not a warranty it will run.
In terms of "relative" importance, consider that mingw (both native and cross) GNU toolchain works well, the toolchain part of cygwin is hardly a priority; further, between mingw and MSVC (note the distinction - I mean mingw, not cygwin), I would rather spend time improving wine's support for MSVC .
That is an interesting observation - getting microsoft products to work well is obviously a priority to the wider community & to Crossover, but that isn't mentioned much in those wiki pages.
On 2013-07-01 06:13+0100 Hin-Tak Leung wrote:
[...]In terms of "relative" importance, consider that mingw (both native and cross) GNU toolchain works well, the toolchain part of cygwin is hardly a priority.
Once again you are implying the MinGW GNU toolchain is better than the Cygwin GNU toolchain without mention of any bug reports from you to Cygwin to back up that assertion. Your constant repetition of this theme made me curious so I looked you up on the web, and it appears you are a MinGW developer.
If you really are a MinGW developer, I hope your negative attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows.
You certainly have the right to express your opinion about the Cygwin toolchain here, and you _might_ even be correct, but I am concerned you are biased since you appear to be broadcasting anecdotal evidence without sending in bug reports to Cygwin concerning what you have found.
And now to get back on topic again, thanks, André, for that reference to http://wiki.winehq.org/CygwinSupport. The two points there are worth repeating:
For Wine, the upside would be: * a very good test suite * a much more solid implementation of the fundamental Win32 APIs
These same points can be made about MinGW/MSYS and my work on building software (whose build is configured by my "build_projects" project) on Wine with that toolchain. And that work has already contributed to 3 Wine fixes (two of which were regressions introduced in the 1.5.x series).
However, it should be emphasized that Cygwin is a very much bigger free software project than MinGW/MSYS. So it provides a much more comprehensive and rigourous test of Wine than MinGW/MSYS, and this will be the case for the forseeable future. The number of software projects whose builds are configured by build_projects is growing, but that number it is still very much smaller than the list of software builds that are included in the Cygwin distribution.
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, 1/7/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote: ... I hope your negative
attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows.
...
Look. You have been advised a few times, that it is possible and even easy to bypass installation-related problems and been given brief instructions on how to do so; you have also been told, *many times*, and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list.
Going personal and accusing others of being biased is not a way of getting help. If you have bothered to look it up as you claim to do, while I have a formal association with mingw, I have made absolutely no contribution to mingw at all, ever; whereas I have made some patches available, etc to cygwin's GNU findutils (merged into coreutils eventually), LaTeX, emacs/xemacs, over a decade ago. My history with cygwin is about twice as old as my association with mingw. That's a matter of public record.
If you bother to look further, the main reason is really that cygwin is a commercial entity - part of Redhat now, but was a privately-own company until 13 years ago when Redhat acquired part of it. Formal membership to cygwin has always been different from how formal membership to mingw operates, for that very reason; and that I live locally to where that company was, (and the part of cygwin that Redhat choose not to buy, still is), and probably know or have met some of the cygwin developers in person. I don't have the fortune to meet/know many, but they have my respects.
The cygwin people would have told you the exact same thing: running mingw on wine is fair easier and more straight-forward, and there are very simple technical reasons why that is the case; and that cygwin is not mingw, and there are important difference where wine is concerned. You seem to assume the difference between cygwin and mingw is small - they are not, and really a world apart, as far as wine is concerned.
Going via exaggeration/sensationalist ("showstoppers") or personal attack is not going to win you any help. FWIW, on the latter point, few are interested in reading a 20-line introduction about your life (or lack of it) every time at the bottom of your posts. That's another thing that put people off from helping you.
On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:
--- On Mon, 1/7/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote: ... I hope your negative
attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows.
...
Look. You have been advised a few times, that it is possible and
even easy to bypass installation-related problems and been given brief instructions on how to do so.
The problem discussed on this thread is not with the generic part of the installation you have referred to but instead the problem is with running one of the post install scripts that is invoked by setup.exe.
you have also been told, *many times*,
and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list.
Many times by you and once by a Cygwin developer. I have answered both, but I am going to try again now since you brought it up again.
Even if that assertion were true (something we don't know until some Wine developer with an interest in Cygwin systematically looks at it for the latest Wine to see how many Cygwin bugs are left for that much improved version of Wine) it only strengthens my argument. The fact remains, Cygwin is open-source software so in theory (i.e., the Wine developer pursuing this opportunity will need some knowledge of Cygwin) you know exactly what is going on with the calls to Windows software, and you can also directly compare results for those calls between the Wine version and Microsoft version of Windows. Therefore I think it is obvious that Cygwin represents a good opportunity to get rid of Wine bugs. If there are a lot of such bugs like you and the Cygwin developer assert, then it represents even a bigger opportunity to debug those Wine issues with exact source code in hand that demonstrates the issue. I think we don't really know what bugs are still left in recent Wine until a systematic evaluation is done of Cygwin on Wine, but my argument stands whether there are a lot of such bugs or only a few.
Going personal and accusing others of being biased is not a way of
getting help. If you have bothered to look it up as you claim to do, while I have a formal association with mingw, I have made absolutely no contribution to mingw at all, ever.
Sourceforge lists you as a MinGW developer, but I believe you when you state that is only a formal association. I knew of that possibility of just a formal association so that is why I was careful to put in phrasing like "apparently", and "if this is true". I am sorry you missed that phrasing and took that as a personal attack.
Regardless of your association or not with MinGW, I am still concerned the opinions you have expressed here on the Cygwin tool chain are biased. That is because I have my own bias. In short, I have a prejudice against anyone stating anecdotal evidence concerning issues with _any_ open-source software if they don't back up that anecdotal evidence with a solid bug report. For example, you stated some anecdotal evidence about a bug in Cygwin "cat", but when I requested a reference for your associated bug report to Cygwin you were silent. That told me a lot.
The cygwin people would have told you the exact same thing: running
mingw on wine is fair easier and more straight-forward.
That is obvious and strengthens the argument for using Cygwin as a debugging tool for Wine.
[...]and that cygwin is
not mingw, and there are important difference where wine is concerned. You seem to assume the difference between cygwin and mingw is small - they are not, and really a world apart, as far as wine is concerned.
You are completely wrong about what I assume. Try reading what I have said earlier today. The two projects are obviously quite different which is why I have stated earlier today that Cygwin represents a different opportunity (and a more extensive opportunity because it is a lot bigger) than MinGW/MSYS to debug Wine. Of course, that opportunity is there only if Cygwin _on Microsoft Windows_ mostly works and is not riddled with bugs. I think that is a fair assumption since Cygwin does have a significant userbase that actually uses it on Microsoft Windows.
Something about this opportunity to use a comparison of Cygwin's behaviour on Microsoft Windows versus the Wine version to debug Wine obviously bothers you, and because of that you have clearly stated you would prefer the Wine developers here ignore this opportunity and work on something else. However, I completely disagree with your opinion about that opportunity. Any fixes to Wine that make it more like Microsoft Windows will help _all_ Windows software being run on Wine. That said, the actual Wine developers here will probably ignore both our opinions and only investigate Cygwin on Wine if that general debugging opportunity interests them. But, of course, that is the way it should be!
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, Jul 1, 2013 at 7:11 PM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:
--- On Mon, 1/7/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote: ... I hope your negative
attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows.
...
Look. You have been advised a few times, that it is possible and
even easy to bypass installation-related problems and been given brief instructions on how to do so.
The problem discussed on this thread is not with the generic part of the installation you have referred to but instead the problem is with running one of the post install scripts that is invoked by setup.exe.
you have also been told, *many times*,
and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list.
Many times by you and once by a Cygwin developer. I have answered both, but I am going to try again now since you brought it up again.
Even if that assertion were true (something we don't know until some Wine developer with an interest in Cygwin systematically looks at it for the latest Wine to see how many Cygwin bugs are left for that much improved version of Wine) it only strengthens my argument. The fact remains, Cygwin is open-source software so in theory (i.e., the Wine developer pursuing this opportunity will need some knowledge of Cygwin) you know exactly what is going on with the calls to Windows software, and you can also directly compare results for those calls between the Wine version and Microsoft version of Windows. Therefore I think it is obvious that Cygwin represents a good opportunity to get rid of Wine bugs. If there are a lot of such bugs like you and the Cygwin developer assert, then it represents even a bigger opportunity to debug those Wine issues with exact source code in hand that demonstrates the issue. I think we don't really know what bugs are still left in recent Wine until a systematic evaluation is done of Cygwin on Wine, but my argument stands whether there are a lot of such bugs or only a few.
While it's likely that debugging this (and other) Cygwin problems with Wine would find and eliminate bugs from Wine, it also takes a lot of effort and know how to do so. That time is often better spent on issues that require less effort to debug, and help more user visible applications.
In other words, while fixing Cygwin issues is a valuable effort, it takes a lot of time and effort that is better spent elsewhere. If you want to spend that time and effort, feel free to do so. But asking others to spend their time to debug issues that fix Cygwin isn't likely to find many volunteers.
-- -Austin
On 2013-07-01 20:08-0700 Austin English wrote:
In other words, while fixing Cygwin issues is a valuable effort, it takes a lot of time and effort that is better spent elsewhere.
Hi Austin:
I agree that fixing Cygwin on Wine issues will take some considerable initial effort learning about Cygwin, but after some Wine developer has made that effort (or if they already have that Cygwin expertise), then in addition they have complete access to the Cygwin source code for the Windows calls that are not properly working on Wine, and that is a big advantage in knocking off Wine problems one by one that are turned up this way. And I want to emphasize again that fixing those Wine problems should be a big advantage for _all_ Windows applications being run on Wine, not just Cygwin.
[...] [A]sking others to spend their time to debug issues that fix Cygwin isn't likely to find many volunteers.
Well, there is at least one volunteer working on this, and he has made some good progress. Andrey Turkin's small patch for Wine (see his attachment at http://bugs.winehq.org/show_bug.cgi?id=24018) combined with the Cygwin fork fix now works for him and me in the sense that the postinstall scripts now all run without catastrophic runtime errors or hangs. I have added all the details about my experience with that breakthrough to that bug report. I have included an attachment there of a script to allow convenient updating of cygwin1.dll with the fork-fixed version.
Note, the first postinstall script that is run creates an empty /etc/fstab rather than the desired result and also fails to create /dev. These errors very likely create problems for the other postinstall scripts and might be some/all of the reason why four of those scripts generate error messages and have non-zero return codes.
So the status right now is that the postinstall scripts run by setup.exe on Wine still do not give clean results, but the results are much better than before the Cygwin fork fix and Andrey's patch. There are probably a couple of Wine bugs that still need to be fixed before clean postinstall script results can be achieved. Of course, a clean result from the postinstall stage of setup.exe would only be the first step, but that step should give solid footing for finding and fixing the rest of the Cygwin on Wine bugs.
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 Tue, 2/7/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
Going personal and accusing others of being biased is
not a way of getting help.
...In short, I have
a prejudice against anyone stating anecdotal evidence concerning issues with _any_ open-source software if they don't back up that anecdotal evidence with a solid bug report. For example, you stated some anecdotal evidence about a bug in Cygwin "cat", but when I requested a reference for your associated bug report to Cygwin you were silent. That told me a lot.
...
That tells you only one thing: I don't care about Cygwin enough now to bother filing one more bug among those already filed. My time is more valuable than that. 13 years ago I used it daily and I made my own contributions, and that was then. Half of the time I file bugs on various projects because I have patches to attach/send, and this is not the case with cygwin now, and will not be. I don't intend to file a bug because I don't intend spend time fixing it. You wish.
I am not the one asking for help - you are. Launching personal attacks on people trying to help you is just not the way to do it. Nor is exaggeration, nor is 20-line of [lack of] life included in every e-mail.
If you want help, ask for it, nicely, and keep it short.
On 2013-06-29 18:33, Alan W. Irwin wrote:
Those have been mentioned before here, and I have looked at them. Cygwin is a very large collection of software so the number of bugs that are reported does not seem excessive to me, and for my personal needs (building and testing software on the Cygwin platform) I will only be using a subset of Cygwin so I may avoid encountering some of these bugs. Furthermore, some of these bugs (e.g., problems resizing a GUI) are not showstoppers, and most of them are quite old. At the same time the latest Wine is far superior to Wine-1.4 so some of those bugs may have just disappeared. I hope to find out about the actual status of Cygwin on Wine bugs once I can get setup.exe to work on Wine.
I would like to point out that it seems that the current bug does not appear to be *in* setup.exe, but rather occurs when setup.exe runs a bash post-install script, where the bash.exe that interprets the script depends on cygwin1.dll. If my analysis is correct, the bug would occur also when duplicating the actions of setup.exe manually. You would have to also duplicate the actions of all post-install scripts, which is certainly more work and more error-prone than duplicating the download and unpacking of a few tarballs.
Cheers, Peter
On 2013-07-01 18:13+0200 Peter Rosin wrote:
On 2013-06-29 18:33, Alan W. Irwin wrote:
Those have been mentioned before here, and I have looked at them. Cygwin is a very large collection of software so the number of bugs that are reported does not seem excessive to me, and for my personal needs (building and testing software on the Cygwin platform) I will only be using a subset of Cygwin so I may avoid encountering some of these bugs. Furthermore, some of these bugs (e.g., problems resizing a GUI) are not showstoppers, and most of them are quite old. At the same time the latest Wine is far superior to Wine-1.4 so some of those bugs may have just disappeared. I hope to find out about the actual status of Cygwin on Wine bugs once I can get setup.exe to work on Wine.
I would like to point out that it seems that the current bug does not appear to be *in* setup.exe, but rather occurs when setup.exe runs a bash post-install script, where the bash.exe that interprets the script depends on cygwin1.dll. If my analysis is correct, the bug would occur also when duplicating the actions of setup.exe manually. You would have to also duplicate the actions of all post-install scripts, which is certainly more work and more error-prone than duplicating the download and unpacking of a few tarballs.
Hi Peter:
That analysis is absolutely correct, and the current hang I am getting for that post-install script (/etc/postinstall/000-cygwin-post-install.sh) is a puzzler since that occurs with or without the fork-fixed cygwin1.dll and the hang is new behaviour compared to the result I got a month ago (obviously without the fork-fixed cygwin1.dll) where I got an abort with an explicit error message in agreement with the 24018 bug report. So I hope others here with some cygwin experience will investigate further since I might be doing something inadvertently different than before when I replicated the behaviour reported in the 24018 bug report exactly.
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, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote:
I would like to point out that it seems that the current bug does not appear to be *in* setup.exe, but rather occurs when setup.exe runs a bash post-install script, where the bash.exe that interprets the script depends on cygwin1.dll. If my analysis is correct, the bug would occur also when duplicating the actions of setup.exe manually.
If you read into what cygwin does when trying to emulate fork() it is surprising it works at all!
Putting some effort into getting the shell (be it bash or an ash derivative) and gmake to use posix_spawn() instead of fork() and adding posix_spawn() to cygwin (for which patches are avaiable) would speed up cygwin no end and probably avoid some of these bugs (and the random fork failed errors).
One day I'll get annoyed at some issues with cygwin and start fixing them! (Like getting ^C to work for windows console programs in mintty windows.)
David
--- On Mon, 1/7/13, David Laight david@l8s.co.uk wrote:
On Mon, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote:
I would like to point out that it seems that the
current bug does not
appear to be *in* setup.exe, but rather occurs when
setup.exe runs
a bash post-install script, where the bash.exe that
interprets the
script depends on cygwin1.dll. If my analysis is
correct, the bug
would occur also when duplicating the actions of
setup.exe manually.
If you read into what cygwin does when trying to emulate fork() it is surprising it works at all!
Putting some effort into getting the shell (be it bash or an ash derivative) and gmake to use posix_spawn() instead of fork() and adding posix_spawn() to cygwin (for which patches are avaiable) would speed up cygwin no end and probably avoid some of these bugs (and the random fork failed errors).
One day I'll get annoyed at some issues with cygwin and start fixing them! (Like getting ^C to work for windows console programs in mintty windows.)
Yap. It is fork/exec, the whole thing around process ids, and stat, inode emulation, as well. It is just not setup.exe - post-install scripts are per-package items and some packages don't have them.
That has been hinted at a few times by the cygwin developers who answered and me. It is "easier" to see what the problem is (or "what the problems are"), by manually unpacking the installing packages and running the scripts by hand - as the cygwin developers had already suggested. And it is even "easier" by-passing it, if one just wants a cygwin installation to play with, by copying from a windows box.
Being able to get through installation, or obtaining an installation, does not change the fact that there are fundamental technical reasons that some part of cygwin does not work well in wine. Not without some serial rewrite in cygwin *and* wine.
cygwin did run on win98 . I used cygwin on win98 regularly then. posix_spawn() wasn't available on the 95/98/ME family.
Since cygwin works well enough on genuine windows (..more or less...), that it can be improved/rewritten does not say the issues are less of a wine problem.
-
Alan W. Irwin -
André Hentschel -
Austin English -
David Laight -
Hin-Tak Leung -
Hin-Tak Leung -
Peter Rosin