Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-04 16:16-0700 Alan W. Irwin wrote: In contrast to 3. The following succeeded: A. project(test CXX Fortran ) B. project(test NONE ) enable_language(Fortran ) enable_language(CXX ) Subsequent tests showed those actually did not succeed. There were no obvious errors, but the cache variable CMAKE_CXX_COMPILER_WORKS was not set. So it appears there is no current way to get CXX working properly for MinGW/MSYS/Wine; there is always some failure due to the interference from Fortran. Hopefully, the fix will be easy to figure out from the cmake --trace --debug-output results I attached to my first post, but if the CMake developers need me to try any more experiments, let me know. 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On Sun, Apr 4, 2010 at 7:16 PM, Alan W. Irwin wrote: > Clint (with an old version of MinGW) and I (with MinGW-4.5) have been > running into a peculiar CXX error for MinGW/MSYS on Wine. > > Enabling C++ _sometimes_ fails because it includes > CMakeFortranInformation.cmake (why?) which then leads to a > "get_filename_component called with incorrect number of arguments" > I had this same problem under wine and using vc2005. I believe the issue is caused by wine pulling in at least some of environment variables from the linux system. The weird thing is this error only occurred with some of my projects. To get around this temporarily disabled the fortran module. John ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-04 21:28-0400 John Drescher wrote: On Sun, Apr 4, 2010 at 7:16 PM, Alan W. Irwin wrote: Clint (with an old version of MinGW) and I (with MinGW-4.5) have been running into a peculiar CXX error for MinGW/MSYS on Wine. Enabling C++ _sometimes_ fails because it includes CMakeFortranInformation.cmake (why?) which then leads to a "get_filename_component called with incorrect number of arguments" I had this same problem under wine and using vc2005. That is a pretty interesting platform as well! I believe the issue is caused by wine pulling in at least some of environment variables from the linux system. That idea of something leaking through from Linux to Wine to disrupt CMake might be possible although I had a quick look at my short list of environment variable using printenv and I didn't spot anything relevant. Of course, the wine registry is huge so there may be some issue in there. Fortunately, that is a human-readable file under Wine so it is easy to grep it for any relevant string. I hope the CMake developers can come up with some ideas about this hypothesis once they pinpoint exactly where things start to go wrong from my --trace results for an extremely simple project. Of course, I would be happy to do further tests of this hypothesis. The weird thing is this error only occurred with some of my projects. Well some of my simple experiments (the ones that enabled Fortran before CXX) looked like they were working until I discovered later that CMAKE_CXX_COMPILER_WORKS was not being set correctly for the ones I thought were initially working. Our PLplot project checks that variable, and if it is not set disables the language but maybe that is not necessary. I will try setting it to ON to see if I can get further with the PLplot C++ testing. To get around this temporarily disabled the fortran module. I found something similar when I moved CMakeFortranInformation.cmake, but I have to double-check now about whether CMAKE_CXX_COMPILER_WORKS was set correctly when Fortran was disabled that way. If this turns out to work, then it won't be particular convenient in the PLplot case (we have to do two test runs rather than one with either C++ or Fortran disabled), but at least it allows us to test the C++ parts of the PLplot build for this platform. I will give that (and the previous idea of setting CMAKE_CXX_COMPILER_WORKS) a shot tomorrow, but I am also looking forward to a real fix for obvious reasons. BTW, for those trying to follow what I did for this platform, I discovered that MinGW-4.4 didn't work at all under Wine until I changed all Linux permissions of the Windows files in bin, libexec, and mingw32 to go+rx. (I presume Wine or CMake must check those permissions.) MinGW-4.5 already had those permissions which is why it worked (except for the noted limitations) right out of the box with CMake. Werner Smekal has advised me that MinGW-4.4 is the recommended version (MinGW-4.5 is a development version) so I will probably stick to 4.4 from now on. Unfortunately, the change from MinGW-4.5 to MinGW-4.4 did not remove any issues. OTOH, it didn't create any either. 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-05 00:40-0700 Alan W. Irwin wrote: On 2010-04-04 21:28-0400 John Drescher wrote: [...] I believe the issue is caused by wine pulling in at least some of environment variables from the linux system. That idea of something leaking through from Linux to Wine to disrupt CMake might be possible [...] I hope the CMake developers can come up with some ideas about this hypothesis once they pinpoint exactly where things start to go wrong from my --trace results for an extremely simple project. Other clues I should have emphasized are that pure C and pure Fortran simple cases have no language interference issues at all. Also if you combine C and Fortran but exclude C++ for PLplot builds and tests, there are no such language interference issues, and the tests look like they are working fine. So it appears that something is being done in the pure CXX case to trigger the Fortran interference that is unique compared to the pure C and pure Fortran cases. 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
Alan W. Irwin wrote: On 2010-04-05 00:40-0700 Alan W. Irwin wrote: On 2010-04-04 21:28-0400 John Drescher wrote: [...] I believe the issue is caused by wine pulling in at least some of environment variables from the linux system. That idea of something leaking through from Linux to Wine to disrupt CMake might be possible [...] I hope the CMake developers can come up with some ideas about this hypothesis once they pinpoint exactly where things start to go wrong from my --trace results for an extremely simple project. Other clues I should have emphasized are that pure C and pure Fortran simple cases have no language interference issues at all. Also if you combine C and Fortran but exclude C++ for PLplot builds and tests, there are no such language interference issues, and the tests look like they are working fine. So it appears that something is being done in the pure CXX case to trigger the Fortran interference that is unique compared to the pure C and pure Fortran cases. Have you run cmake --trace yet to figure out what is including what and where? -Bill ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-05 11:31-0400 Bill Hoffman wrote: Alan W. Irwin wrote: On 2010-04-05 00:40-0700 Alan W. Irwin wrote: On 2010-04-04 21:28-0400 John Drescher wrote: [...] I believe the issue is caused by wine pulling in at least some of environment variables from the linux system. That idea of something leaking through from Linux to Wine to disrupt CMake might be possible [...] I hope the CMake developers can come up with some ideas about this hypothesis once they pinpoint exactly where things start to go wrong from my --trace results for an extremely simple project. Other clues I should have emphasized are that pure C and pure Fortran simple cases have no language interference issues at all. Also if you combine C and Fortran but exclude C++ for PLplot builds and tests, there are no such language interference issues, and the tests look like they are working fine. So it appears that something is being done in the pure CXX case to trigger the Fortran interference that is unique compared to the pure C and pure Fortran cases. Have you run cmake --trace yet to figure out what is including what and where? Yes, as alluded to above the complete result for cmake --trace --debug-output for a CMakeLists.txt file consisting of just project(test NONE) enable_language(CXX) was attached to my first post in this thread. Part way through is starts accessing CMakeFortranInformation.cmake which is the source of the trouble. For your convenience I will attach that cmake output to this post as well. 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 __ cmake.out.gz Description: cmake --trace --debug-output results for simple case ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
Alan W. Irwin wrote:
Have you run cmake --trace yet to figure out what is including what
and where?
Yes, as alluded to above
the complete result for cmake --trace --debug-output for
a CMakeLists.txt file consisting of just
project(test NONE)
enable_language(CXX)
was attached to my first post in this thread. Part way through is starts
accessing CMakeFortranInformation.cmake which is the source of the trouble.
For your convenience I will attach that cmake output to this post as well.
OK, you are going to have to look at the C++ code to figure this out.
You will need to add some debug prints to this function:
void
cmGlobalGenerator::EnableLanguage(std::vectorconst& languages,
cmMakefile *mf, bool)
...
for(std::vector::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
Seems that Fortran is getting into the list of enabled languages.
Might also want to put prints in cmEnableLanguageCommand
::InitialPass and void
cmMakefile::EnableLanguage(std::vector const & lang,
bool optional)
-Bill
___
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On Apr 5, 2010, at 11:50 AM, Bill Hoffman wrote:
> Alan W. Irwin wrote:
>
>>> Have you run cmake --trace yet to figure out what is including what and
>>> where?
>> Yes, as alluded to above
>> the complete result for cmake --trace --debug-output for
>> a CMakeLists.txt file consisting of just
>> project(test NONE)
>> enable_language(CXX)
>> was attached to my first post in this thread. Part way through is starts
>> accessing CMakeFortranInformation.cmake which is the source of the trouble.
>> For your convenience I will attach that cmake output to this post as well.
>
> OK, you are going to have to look at the C++ code to figure this out.
>
> You will need to add some debug prints to this function:
>
> void
> cmGlobalGenerator::EnableLanguage(std::vectorconst& languages,
> cmMakefile *mf, bool)
>
> ...
>
> for(std::vector::const_iterator l = languages.begin();
> l != languages.end(); ++l)
>{
>
> Seems that Fortran is getting into the list of enabled languages.
>
> Might also want to put prints in cmEnableLanguageCommand
> ::InitialPass and void cmMakefile::EnableLanguage(std::vector
> const & lang,
> bool optional)
>
>
So interleaving wine tracing and cmake tracing along with some debugging... the
problem comes from within SystemTools::GetActualCaseForPath()
where it takes as input /CMakeTestCXXCompiler.cmake and returns
/CMakeFortranInformation.cmake.
I'm guessing its a bug in Wine's GetShortPathName() or GetLongPathName().
There are more modern apis for getting the actual case of a file, but they
probably don't work on Windows 98.
Clint
___
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-05 13:50-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
Have you run cmake --trace yet to figure out what is including what and
where?
Yes, as alluded to above
the complete result for cmake --trace --debug-output for
a CMakeLists.txt file consisting of just
project(test NONE)
enable_language(CXX)
was attached to my first post in this thread. Part way through is starts
accessing CMakeFortranInformation.cmake which is the source of the trouble.
For your convenience I will attach that cmake output to this post as well.
OK, you are going to have to look at the C++ code to figure this out.
You will need to add some debug prints to this function:
void
cmGlobalGenerator::EnableLanguage(std::vectorconst& languages,
cmMakefile *mf, bool)
...
for(std::vector::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
Seems that Fortran is getting into the list of enabled languages.
Might also want to put prints in cmEnableLanguageCommand
::InitialPass and void cmMakefile::EnableLanguage(std::vector
const & lang,
bool optional)
Hi Bill:
Thanks for that advice.
It turns out that the workaround of disabling Fortran that has been
mentioned in this thread does allow CXX to be enabled properly so I have
been able to build and test the CXX components of PLplot this morning (so
long as I drop the Fortran components of PLplot and disable CMake Fortran
support by renaming CMakeFortranInformation.cmake).
Therefore, I am fairly confident I can now build CMake with the cmake app on
MinGW/MSYS/Wine (so long as I disable CMake Fortran support), but I haven't
tried that yet. Also, MinGW apparently provides gdb so I will try to get
that going as well. Although my C and gdb skills are fine, my C++ skills are
not that good and I am not that familiar with the CMake code so this will
take some time even with the clues you have given me above about where
to look.
I hope to be able to report back with gdb results before the weekend.
Meanwhile, if any of the CMake developers are interested in reproducing this
issue for themselves, it is completely straightforward to get access to the
MinGW/MSYS/Wine platform, and I state that as a complete MinGW/MSYS/Wine
newbie (no experience with MinGW, MSYS, or Wine at all until late last
week). It is simply a matter of installing wine-1.4.1 on Linux, downloading
and unpacking Windows versions of MinGW, MSYS, and CMake, running winecfg
(with default choices), putting those packages on the PATH via editing the
wine registry file, .wine/system.reg, and you have liftoff. I have kept a
complete cookbook of what I did (including all the wget URL's for the MinGW
and MSYS componnents where collecting those URLs was the most time-consuming
part of the process). I would be happy to share that cookbook.
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
Clinton Stimpson wrote: So interleaving wine tracing and cmake tracing along with some debugging... the problem comes from within SystemTools::GetActualCaseForPath() where it takes as input /CMakeTestCXXCompiler.cmake and returns /CMakeFortranInformation.cmake. I'm guessing its a bug in Wine's GetShortPathName() or GetLongPathName(). There are more modern apis for getting the actual case of a file, but they probably don't work on Windows 98. Yikes! That is a nice bug... I would expect it to cause lots of other really strange things to happen as well I don't think there is much that can be done about that... What are the more modern ways of doing that? We don't really support windows 98 anymore. NT and greater. -Bill ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-05 13:04-0600 Clinton Stimpson wrote:
On Apr 5, 2010, at 11:50 AM, Bill Hoffman wrote:
Alan W. Irwin wrote:
Have you run cmake --trace yet to figure out what is including what and where?
Yes, as alluded to above
the complete result for cmake --trace --debug-output for
a CMakeLists.txt file consisting of just
project(test NONE)
enable_language(CXX)
was attached to my first post in this thread. Part way through is starts
accessing CMakeFortranInformation.cmake which is the source of the trouble.
For your convenience I will attach that cmake output to this post as well.
OK, you are going to have to look at the C++ code to figure this out.
You will need to add some debug prints to this function:
void
cmGlobalGenerator::EnableLanguage(std::vectorconst& languages,
cmMakefile *mf, bool)
...
for(std::vector::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
Seems that Fortran is getting into the list of enabled languages.
Might also want to put prints in cmEnableLanguageCommand
::InitialPass and void cmMakefile::EnableLanguage(std::vector const
& lang,
bool optional)
So interleaving wine tracing and cmake tracing along with some
debugging... the problem comes from within
SystemTools::GetActualCaseForPath() where it takes as input
/CMakeTestCXXCompiler.cmake and returns
/CMakeFortranInformation.cmake. I'm guessing its a bug in Wine's
GetShortPathName() or GetLongPathName(). There are more modern apis for
getting the actual case of a file, but they probably don't work on Windows
98.
Hi Clint:
Thanks for debugging it this far. I (obviously) wasn't looking forward
to setting that up for myself.
From the code itself in kwsys/SystemTools.cxx it just simply returns what is
input for the non-Windows case. So is the input you referred to above
actually /CMakeCXXInformation.cmake rather than
/CMakeTestCXXCompiler.cmake? If you actually reporyed that input
correctly it sounds like SystemTools::GetActualCaseForPath() is
"remembering" values from a previous call which might be an issue in the
CMake C++ code itself when something else is going wrong (say on the Wine
side).
Also, could you look further to see why "project(test CXX)" generates this
error while "project(test C)" does not? Assuming "project(test C)" does use
this code path, why are correct results being returned in that case but not
for CXX?
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On Apr 5, 2010, at 2:19 PM, Bill Hoffman wrote: > Clinton Stimpson wrote: > >> So interleaving wine tracing and cmake tracing along with some > debugging... the problem comes from within > SystemTools::GetActualCaseForPath() >> where it takes as input /CMakeTestCXXCompiler.cmake and > returns /CMakeFortranInformation.cmake. >> I'm guessing its a bug in Wine's GetShortPathName() or > GetLongPathName(). There are more modern apis for getting the actual > case of a file, but they probably don't work on Windows 98. > > Yikes! > > That is a nice bug... I would expect it to cause lots of other really > strange things to happen as well > > I don't think there is much that can be done about that... What are the > more modern ways of doing that? We don't really support windows 98 anymore. > NT and greater. I was thinking SHGetFileInfo() would be a modern way of doing it, but there is more work involved to use it. I'd prefer wine be fixed than cmake having a workaround. Clint ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 04/05/2010 03:00 PM, Alan W. Irwin wrote:
On 2010-04-05 13:04-0600 Clinton Stimpson wrote:
On Apr 5, 2010, at 11:50 AM, Bill Hoffman wrote:
Alan W. Irwin wrote:
Have you run cmake --trace yet to figure out what is including
what and where?
Yes, as alluded to above
the complete result for cmake --trace --debug-output for
a CMakeLists.txt file consisting of just
project(test NONE)
enable_language(CXX)
was attached to my first post in this thread. Part way through is
starts
accessing CMakeFortranInformation.cmake which is the source of the
trouble.
For your convenience I will attach that cmake output to this post
as well.
OK, you are going to have to look at the C++ code to figure this out.
You will need to add some debug prints to this function:
void
cmGlobalGenerator::EnableLanguage(std::vectorconst&
languages,
cmMakefile *mf, bool)
...
for(std::vector::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
Seems that Fortran is getting into the list of enabled languages.
Might also want to put prints in cmEnableLanguageCommand
::InitialPass and void
cmMakefile::EnableLanguage(std::vector const & lang,
bool optional)
So interleaving wine tracing and cmake tracing along with some
debugging... the problem comes from within
SystemTools::GetActualCaseForPath() where it takes as input
/CMakeTestCXXCompiler.cmake and returns
/CMakeFortranInformation.cmake. I'm guessing its a bug in
Wine's
GetShortPathName() or GetLongPathName(). There are more modern apis for
getting the actual case of a file, but they probably don't work on
Windows
98.
Hi Clint:
Thanks for debugging it this far. I (obviously) wasn't looking forward
to setting that up for myself.
From the code itself in kwsys/SystemTools.cxx it just simply returns
what is
input for the non-Windows case. So is the input you referred to above
actually /CMakeCXXInformation.cmake rather than
/CMakeTestCXXCompiler.cmake? If you actually reporyed that
input
correctly it sounds like SystemTools::GetActualCaseForPath() is
"remembering" values from a previous call which might be an issue in the
CMake C++ code itself when something else is going wrong (say on the Wine
side).
Also, could you look further to see why "project(test CXX)" generates
this
error while "project(test C)" does not? Assuming "project(test C)"
does use
this code path, why are correct results being returned in that case
but not
for CXX?
I've submitted a bug report to the wine bugzilla with a very simple test
case (bug #22286). So the bug can be taken care of or discussed over there.
If anyone needs a workaround until its fixed, just modify
kwsys/SystemTools.cxx's PortableGetLongPathName() to use
OldWindowsGetLongPath() instead of GetLongPathNameA() from kernel32.dll.
Clint
___
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-05 19:21-0600 Clinton Stimpson wrote:
I've submitted a bug report to the wine bugzilla with a very simple test case
(bug #22286). So the bug can be taken care of or discussed over there.
If anyone needs a workaround until its fixed, just modify
kwsys/SystemTools.cxx's PortableGetLongPathName() to use
OldWindowsGetLongPath() instead of GetLongPathNameA() from kernel32.dll.
I managed to bootstrap my way out of this mess for MinGW/MSYS/Wine using
that workaround.
Here is how.
I implemented your workaround recommendation using the following trivial
patch to the CMake source code:
--- SystemTools.cxx_original2010-04-05 22:03:48.0 -0700
+++ SystemTools.cxx 2010-04-05 22:05:38.0 -0700
@@ -3114,6 +3114,7 @@
kwsys_stl::string & longPath)
{
HMODULE lh = LoadLibrary("Kernel32.dll");
+ lh = NULL;
if(lh)
{
FARPROC proc = GetProcAddress(lh, "GetLongPathNameA");
I disabled Fortran in the downloaded Windows binary version of CMake by
moving
cmake-2.8.1-win32-x86/share/cmake-2.8/Modules/CMakeFortranInformation.cmake
I built and installed CMake from source (with the above patch) using the
downloaded Windows binary cmake app. There were no obvious issues at
all (which is a strong CXX test of CMake under MinGW/MSYS/Wine.)
That built version of CMake-2.8.1 does not have to have Fortran disabled,
and therefore PLplot builds and tests using C, C++, Fortran 77, and Fortran
95 with no obvious CMake run-time issues (other than the diverted log file
output I have mentioned on the "noisy CMake" thread) or PLplot build or test
issues. That is a strong C, CXX, and Fortran test of CMake under
MinGW/MSYS/Wine. I will be adding Python, Java, and Tcl to
my MinGW/MSYS/Wine tests of PLplot as time permits.
I have now had a bit of practical experience with the MinGW/MSYS/Wine/CMake
development environment in building both CMake and PLplot (and qhull). With
the above bootstrapped workaround for wine bug 22286, it appears to be fine.
I am still of the opinion that it is going to be a revolutionary combination
since it makes the extremely popular MinGW/MSYS development packages
conveniently available to _all_ developers now for free and with software
freedom regardless of the platform used by those developers.
Thanks, Clint, for all your practical help getting this development
environment working.
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On Tue, Apr 6, 2010 at 2:38 AM, Alan W. Irwin wrote:
> On 2010-04-05 19:21-0600 Clinton Stimpson wrote:
>
> I've submitted a bug report to the wine bugzilla with a very simple test
>> case (bug #22286). So the bug can be taken care of or discussed over there.
>>
>> If anyone needs a workaround until its fixed, just modify
>> kwsys/SystemTools.cxx's PortableGetLongPathName() to use
>> OldWindowsGetLongPath() instead of GetLongPathNameA() from kernel32.dll.
>>
>
> I managed to bootstrap my way out of this mess for MinGW/MSYS/Wine using
> that workaround.
>
> Here is how.
>
> I implemented your workaround recommendation using the following trivial
> patch to the CMake source code:
>
> --- SystemTools.cxx_original2010-04-05 22:03:48.0 -0700
> +++ SystemTools.cxx 2010-04-05 22:05:38.0 -0700
> @@ -3114,6 +3114,7 @@
> kwsys_stl::string & longPath)
> {
> HMODULE lh = LoadLibrary("Kernel32.dll");
> + lh = NULL;
> if(lh)
> {
> FARPROC proc = GetProcAddress(lh, "GetLongPathNameA");
>
> I disabled Fortran in the downloaded Windows binary version of CMake by
> moving
> cmake-2.8.1-win32-x86/share/cmake-2.8/Modules/CMakeFortranInformation.cmake
>
> I built and installed CMake from source (with the above patch) using the
> downloaded Windows binary cmake app. There were no obvious issues at
> all (which is a strong CXX test of CMake under MinGW/MSYS/Wine.)
>
> That built version of CMake-2.8.1 does not have to have Fortran disabled,
> and therefore PLplot builds and tests using C, C++, Fortran 77, and Fortran
> 95 with no obvious CMake run-time issues (other than the diverted log file
> output I have mentioned on the "noisy CMake" thread) or PLplot build or
> test
> issues. That is a strong C, CXX, and Fortran test of CMake under
> MinGW/MSYS/Wine. I will be adding Python, Java, and Tcl to
> my MinGW/MSYS/Wine tests of PLplot as time permits.
>
> I have now had a bit of practical experience with the MinGW/MSYS/Wine/CMake
> development environment in building both CMake and PLplot (and qhull). With
> the above bootstrapped workaround for wine bug 22286, it appears to be
> fine.
> I am still of the opinion that it is going to be a revolutionary
> combination
> since it makes the extremely popular MinGW/MSYS development packages
> conveniently available to _all_ developers now for free and with software
> freedom regardless of the platform used by those developers.
>
> Thanks, Clint, for all your practical help getting this development
> environment working.
>
>
> 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
>
A "real" fix for this has been committed to the CVS repository for kwsys.
The change should appear in the CMake git repository shortly on 'master'...
Thanks to Clinton Stimpson for the patch.
cvs commit -m "Patch to avoid short name usage where possible. Get the
actual case spelling of a file name on 'Windows' without converting to short
name and back again. Avoids bad behavior reported in
http://bugs.winehq.org/show_bug.cgi?id=22286 when using cmake under a
wine/msys/mingw installation on a Linux box. Thanks to Clinton Stimpson for
preparing the patch."
/cvsroot/KWSys/KWSys/SystemTools.cxx,v <-- SystemTools.cxx
new revision: 1.257; previous revision: 1.256
___
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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-04-09 12:17-0400 David Cole wrote: A "real" fix for this has been committed to the CVS repository for kwsys. The change should appear in the CMake git repository shortly on 'master'... Thanks to Clinton Stimpson for the patch. cvs commit -m "Patch to avoid short name usage where possible. Get the actual case spelling of a file name on 'Windows' without converting to short name and back again. Avoids bad behavior reported in http://bugs.winehq.org/show_bug.cgi?id=22286 when using cmake under a wine/msys/mingw installation on a Linux box. Thanks to Clinton Stimpson for preparing the patch." /cvsroot/KWSys/KWSys/SystemTools.cxx,v <-- SystemTools.cxx new revision: 1.257; previous revision: 1.256 Hi David: Sorry for the long delay in responding to you. I am just now restarting testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42). I did find the patch at the "patch" link accessible from http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3 I notice the following result after applying the patch softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath ./Source/kwsys/SystemTools.cxx Further investigation indicates bool SystemTools::GetShortPath is defined that appears to be unused anywhere else in the source tree now that the patch has been applied. Therefore, shouldn't that method be removed? 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On Thu, Jun 10, 2010 at 5:37 PM, Alan W. Irwin wrote: > On 2010-06-10 16:20-0400 David Cole wrote: > > On Thu, Jun 10, 2010 at 4:17 PM, Alan W. Irwin > > >> wrote: >> On 2010-04-09 12:17-0400 David Cole wrote: >> >>A "real" fix for this has been committed to the CVS >>repository for kwsys. >>The change should appear in the CMake git repository >>shortly on 'master'... >> >>Thanks to Clinton Stimpson for the patch. >> >> >>cvs commit -m "Patch to avoid short name usage where >>possible. Get the >>actual case spelling of a file name on 'Windows' >>without converting to short >>name and back again. Avoids bad behavior reported in >>http://bugs.winehq.org/show_bug.cgi?id=22286 when >>using cmake under a >>wine/msys/mingw installation on a Linux box. Thanks >>to Clinton Stimpson for >>preparing the patch." >> >>/cvsroot/KWSys/KWSys/SystemTools.cxx,v <-- >>SystemTools.cxx >>new revision: 1.257; previous revision: 1.256 >> >> >> Hi David: >> >> Sorry for the long delay in responding to you. I am just now >> restarting >> testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42). >> >> I did find the patch at the "patch" link accessible from >> >> http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcb >> bb7be27f49d3 >> >> I notice the following result after applying the patch >> >> softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath >> ./Source/kwsys/SystemTools.cxx >> >> Further investigation indicates bool SystemTools::GetShortPath is >> defined >> that appears to be unused anywhere else in the source tree now that >> the >> patch has been applied. Therefore, shouldn't that method be removed? >> >> >> kwsys code is shared among many, many projects. It appears in way more >> than >> just CMake. So removing a function from any of its interfaces is really >> probably not a very good idea. :-) >> > > I didn't realize external projects used parts of CMake source code, but > your point is well taken in that case. > > That leads to the obvious next question of why aren't those externally used > parts of CMake source code built as a library rather than (presumably) > repeating the compilation for every external project that needs to use the > source code for CMake? I guess it wouldn't matter much for just a few such > external projects, but you say there are many. kwsys builds in less than a minute nearly everywhere, even on slow, older machines... It is built as a library, but built from source in each project that uses it. It's configured into a configurable namespace chosen by the containing project. kwsys is a shared entity. CMake is just one client of it. We include it in the CMake source tree so that the CMake source tree builds without external dependencies. Same reason we include, for example, Utilities/cmcurl and libarchive, etc, etc. David ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On Thu, Jun 10, 2010 at 4:17 PM, Alan W. Irwin wrote: > On 2010-04-09 12:17-0400 David Cole wrote: > > A "real" fix for this has been committed to the CVS repository for kwsys. >> The change should appear in the CMake git repository shortly on >> 'master'... >> >> Thanks to Clinton Stimpson for the patch. >> >> >> cvs commit -m "Patch to avoid short name usage where possible. Get the >> actual case spelling of a file name on 'Windows' without converting to >> short >> name and back again. Avoids bad behavior reported in >> http://bugs.winehq.org/show_bug.cgi?id=22286 when using cmake under a >> wine/msys/mingw installation on a Linux box. Thanks to Clinton Stimpson >> for >> preparing the patch." >> >> /cvsroot/KWSys/KWSys/SystemTools.cxx,v <-- SystemTools.cxx >> new revision: 1.257; previous revision: 1.256 >> > > Hi David: > > Sorry for the long delay in responding to you. I am just now restarting > testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42). > > I did find the patch at the "patch" link accessible from > > http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3 > > I notice the following result after applying the patch > > softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath > ./Source/kwsys/SystemTools.cxx > > Further investigation indicates bool SystemTools::GetShortPath is defined > that appears to be unused anywhere else in the source tree now that the > patch has been applied. Therefore, shouldn't that method be removed? > > kwsys code is shared among many, many projects. It appears in way more than just CMake. So removing a function from any of its interfaces is really probably not a very good idea. :-) David ___ 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-06-10 16:20-0400 David Cole wrote: softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath ./Source/kwsys/SystemTools.cxx Wrong search. Sorry about that noise! If instead you search for GetShortPath there are lots of places in the CMake source tree that still refers to that method. softw...@raven> find -print0 -type f |xargs -0 grep -l GetShortPath ./ChangeLog.txt ./Source/cmCTest.h ./Source/cmLocalVisualStudio6Generator.cxx ./Source/cmGlobalVisualStudio6Generator.cxx ./Source/cmSystemTools.cxx ./Source/cmGlobalVisualStudio7Generator.cxx ./Source/kwsys/SystemTools.cxx ./Source/kwsys/SystemTools.hxx.in ./Source/cmGlobalGenerator.cxx ./Source/cmCTest.cxx ./Source/cmGlobalVisualStudio10Generator.cxx ./Source/cmLocalGenerator.cxx ./Source/CTest/cmCTestMemCheckHandler.cxx ./Source/CTest/cmCTestTestHandler.cxx ./Source/CTest/cmCTestCoverageHandler.cxx ./Source/cmLocalUnixMakefileGenerator3.cxx 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? 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 2010-06-10 16:20-0400 David Cole wrote: On Thu, Jun 10, 2010 at 4:17 PM, Alan W. Irwin wrote: On 2010-04-09 12:17-0400 David Cole wrote: A "real" fix for this has been committed to the CVS repository for kwsys. The change should appear in the CMake git repository shortly on 'master'... Thanks to Clinton Stimpson for the patch. cvs commit -m "Patch to avoid short name usage where possible. Get the actual case spelling of a file name on 'Windows' without converting to short name and back again. Avoids bad behavior reported in http://bugs.winehq.org/show_bug.cgi?id=22286 when using cmake under a wine/msys/mingw installation on a Linux box. Thanks to Clinton Stimpson for preparing the patch." /cvsroot/KWSys/KWSys/SystemTools.cxx,v <-- SystemTools.cxx new revision: 1.257; previous revision: 1.256 Hi David: Sorry for the long delay in responding to you. I am just now restarting testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42). I did find the patch at the "patch" link accessible from http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcb bb7be27f49d3 I notice the following result after applying the patch softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath ./Source/kwsys/SystemTools.cxx Further investigation indicates bool SystemTools::GetShortPath is defined that appears to be unused anywhere else in the source tree now that the patch has been applied. Therefore, shouldn't that method be removed? kwsys code is shared among many, many projects. It appears in way more than just CMake. So removing a function from any of its interfaces is really probably not a very good idea. :-) I didn't realize external projects used parts of CMake source code, but your point is well taken in that case. That leads to the obvious next question of why aren't those externally used parts of CMake source code built as a library rather than (presumably) repeating the compilation for every external project that needs to use the source code for CMake? I guess it wouldn't matter much for just a few such external projects, but you say there are many. 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
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
On 6/10/2010 6:27 PM, Alan W. Irwin wrote: On 2010-06-10 16:20-0400 David Cole wrote: softw...@raven> find -print0 -type f |xargs -0 grep -l shortPath ./Source/kwsys/SystemTools.cxx Wrong search. Sorry about that noise! If instead you search for GetShortPath there are lots of places in the CMake source tree that still refers to that method. softw...@raven> find -print0 -type f |xargs -0 grep -l GetShortPath ./ChangeLog.txt ./Source/cmCTest.h ./Source/cmLocalVisualStudio6Generator.cxx ./Source/cmGlobalVisualStudio6Generator.cxx ./Source/cmSystemTools.cxx ./Source/cmGlobalVisualStudio7Generator.cxx ./Source/kwsys/SystemTools.cxx ./Source/kwsys/SystemTools.hxx.in ./Source/cmGlobalGenerator.cxx ./Source/cmCTest.cxx ./Source/cmGlobalVisualStudio10Generator.cxx ./Source/cmLocalGenerator.cxx ./Source/CTest/cmCTestMemCheckHandler.cxx ./Source/CTest/cmCTestTestHandler.cxx ./Source/CTest/cmCTestCoverageHandler.cxx ./Source/cmLocalUnixMakefileGenerator3.cxx 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, and wine is so busted because of this, and they are being lazy not fixing it correctly IMO It will not be easy to replace. 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. -Bill ___ 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
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 0x at address 0x4015e0 (thread 001f), starting debugger... Start 17: kwsys.testProcess-5 wine: Unhandled page fault on write access to 0x 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 0x 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 sl
Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine
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 To: Bill Hoffman Cc: cmake Mailing List 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 0x at address 0x4015e0 (thread 001f), starting debugger... Start 17: kwsys.testProcess-5 wine: Unhandled page fault on write access to 0x 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 0x 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 developmen
