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 __________________________