[CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Wed Jun 16 12:20:41 EDT 2010
Hi Bill:
I suspect the questions below got lost in the stack of e-mail over last
weekend. Anyhow, I am still very much interested in the answers since all
questions concern possible limitations in the MinGW/MSYS/CMake/Wine
platform, and I am currently putting together a writeup of that platform in
Wiki form.
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); PLplot scientific plotting software
package (plplot.org); 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
__________________________
---------- Forwarded message ----------
Date: Fri, 11 Jun 2010 10:52:31 -0700 (PDT)
From: Alan W. Irwin <irwin at beluga.phys.uvic.ca>
To: Bill Hoffman <bill.hoffman at kitware.com>
Cc: cmake Mailing List <cmake at cmake.org>
Subject: Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for
MinGW/MSYS/Wine
On 2010-06-10 22:24-0400 Bill Hoffman wrote:
>> GetShortPath calls GetShortPathName. From
>> http://bugs.winehq.org/show_bug.cgi?id=22286 it appears the point of
>> Clint's
>> patch was to eliminate a specific and well-known hash collision on Wine
>> caused by GetShortPathName, but from all the on-going uses of GetShortPath
>> within CMake shown above, I am concerned there might be other wine name
>> collisions lurking about with cmake causing other issues (e.g., the wine
>> issue
>> I mentioned before where part of the CMake log messages were not being
>> sent to
>> the log file). To address those potential issues, is
>> there a simple way to reduce or eliminate the use of GetShortPath from the
>> CMake code or else replace the call to GetShortPathName within GetShortPath
>> by something else?
> No, I don't think there is an easy way to get rid of these calls...
I am sure there are good reasons, but could you let me know why CMake needs to
call GetShortPathName (indirectly via GetShortPath) any more? I have no
Windows experience other than this (so far brief) foray into Wine, but I
thought long file names were now standard on Windows.
>
> I suppose one thing you could try is do have an ifdef wine, and when you call
> GetShortPath make it a no-opp. Paths with spaces will likely fail, but it
> would be a good way to see if this is causing other problems.
That is a good idea.
Since I am only using this particular CMake source tree for Wine,
I inserted this into the GetShortPath code:
std::cerr << "Aborting after call to SystemTools::GetShortPath with path =";
std::cerr << path;
exit(1);
My C++ skills are limited so I hope this is a reasonable way to exit the
code if there is any attempt to use GetShortPath.
Under Wine I built cmake with that change, and then used that version to
build cmake again (using the "MinGW Makefiles" generator) with no issues.
I then tried ctest under Wine for that cmake build as follows
wine ctest -j4 >& ctest.out
Some of the tests failed (which I also verified by running them singly).
For the "Unhandled page fault" ones below, they hung rather then ever
reaching the stage where the summary line was given.
Start 16: kwsys.testProcess-4
wine: Unhandled page fault on write access to 0x00000000 at address 0x4015e0
(thread 001f), starting debugger...
Start 17: kwsys.testProcess-5
wine: Unhandled page fault on write access to 0x00000000 at address 0x4015e0
(thread 0018), starting debugger...
22/153 Test #22: CommandLineTest ..................***Timeout 1500.34 sec
Start 114: CTestTestCrash
wine: Unhandled page fault on write access to 0x00000000 at address 0x4013da
(thread 0036), starting debugger...
123/153 Test #121: CTestTestFailedSubmit-ftp ..............***Failed
Required regular expression not found.Regex=[(Problems when submitting via
S*CP|Error message was: ([Cc]ould *n.t resolve host|[Cc]ould *n.t connect to
host|The requested URL returned error|libcurl was built with SSL disabled.
https: not supported)|Submission method .xmlrpc. not compiled into
CTest|Submission successful)
] 52.66 sec
[...]
151/153 Test #150: CMake.GetPrerequisites .................***Exception:
SegFault292.82 sec
152/153 Test #126: Fortran ................................***Failed 405.16
sec
It does appear that none of these failures have anything to do with
GetShortPath if I aborted that possibility correctly above.
I don't know for sure, but my guess is the Fortran error is due to
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2981639&group_id=2435
which is a complete showstopper for compiling Fortran 95 source code with
MinGW gfortran on Wine.
To help understand the above timeout error, my experience with the wine
development environment is it is quite sluggish compared to the Linux
development environment. For example, the MSYS 'ls' command requires 0.244
seconds to complete compared to the Linux 'ls' command which takes 0.002
seconds to complete on the same directory. I assume most of this difference
is start-up latency since lots of near-instantanous commands on Linux that I
try on MSYS take near 0.25 seconds to complete. For something more
sustained like a software build, there are significant speed differences
(typically 3x slower for Wine compared to a Linux build). Some of
that is the latency (since typically many instances of gcc and other commands
are launched during a build), and I ascribe the rest of the difference
to differences in speed between gcc-4.5.0 for MinGW and gcc-4.3.2 that
I am using on my Debian Lenny platform.
Note, I am taking two measures recommended on the web to speed up Wine. I
run the "wineserver -p" command and I also set the environment variable
WINEDEBUG='-all' before launching wine. For any other Wine users here: is
there something more I can do to speed up Wine? I must say I am a bit
surprised at how sluggishit is considering one of its original motivations
was to allow Windows games to run on Linux, and that is an environment where
slowness is not tolerated very well. Of course, the differences I am seeing
could all be due to start up latency and different compiler versions used
for builds, and those factors would not affect games players.
To finish up this speed topic, I have a further question for the CMake
developers: what does the above CommandLineTest consist of? If thousands of
instances of cmake are launched, then the large Wine latency for each
command that it launches is probably generating the timeout error.
Final questions for the CMake developers: How critical in general are the
above test failures? My guess is the answer will be not too critical
(except for the known Fortran 95 issue) since CMake itself and all
components (except for Fortran 95) I have tested so far with PLplot seem to
build without issues. Does MinGW-4.5.0 (as opposed to some earlier version)
have a clean ctest result for the cmake build on a Microsoft Windows
platform? Or do some of the above ctest errors on Wine show up on Microsoft
Windows as well?
I want to emphasize that I am not too discouraged by the above errors since
it is early days yet for Wine as a pure development platform. The ctest
errors that did occur (aside from the Fortran one) seem not to be important
ones (at least from the perspective of building PLplot and cmake.) Despite
the slow speed MinGW (and also MinGW/MSYS) already seem usable (except for
Fortran 95) on Wine to test out Windows build-system issues on a free (as in
cost and also as in software freedom) Windows platform. Helping to track
down and fix Windows build-system issues was my original motivation for
getting into this so I am pleased with these results so far, and there also
appears to be a lot of potential for expanding the use of pure Wine
development in ways not directly related to Windows build-system testing.
For example, in limited testing the pure Wine development method already
seems to work for building and testing Windows apps from Linux so it may
eventually replace cross-compilation as the method of choice for doing that.
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); PLplot scientific plotting software
package (plplot.org); 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
__________________________
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
More information about the CMake
mailing list