From: phil r. <phi...@ya...> - 2014-04-04 15:05:56
|
Hi Thorsten I remember finding some similar linker issue on my Windows system. My memory is telling me it was a lower case l that was prepended, but it might have been the same thing as you. I just tried to find my posts to the list to confirm either way, but I can't find them. From memory it seemed almost like a buffer overrun thing. I spent some time adding debug output to try to find where it got appended and it was related to checking for D, but I like you haven't got a D compiler. Explicitly adding -DENABLE_d=OFF to my command line fixed the problem for me. |
From: phil r. <phi...@ya...> - 2014-04-04 15:10:53
|
Hi Thorsten I remember finding some similar linker issue on my Windows system. My memory is telling me it was a lower case l that was prepended, but it might have been the same thing as you. I just tried to find my posts to the list to confirm either way, but I can't find them. From memory it seemed almost like a buffer overrun thing. I spent some time adding debug output to try to find where it got appended and it was related to checking for D, but I like you haven't got a D compiler. Explicitly adding -DENABLE_d=OFF to my command line fixed the problem for me. Phil PS sorry if this is posted twice - my webmail is not playing nicely this afternoon ________________________________ |
From: Thorsten B. <tho...@do...> - 2014-04-04 15:27:46
|
Hi Phil! > I remember finding some similar linker issue on my Windows system. My > memory is telling me it was a lower case l that was prepended, but it > might have been the same thing as you. I just tried to find my posts to > the list to confirm either way, but I can't find them. From memory it > seemed almost like a buffer overrun thing. I spent some time adding > debug output to try to find where it got appended and it was related to > checking for D, but I like you haven't got a D compiler. Explicitly > adding -DENABLE_d=OFF to my command line fixed the problem for me. Astonishment!!! I ran CMake again building PLplot, but this time with -DENABLE_d=OFF added to the command line. Now, all the linker input directives are given correctly, i.e. without this strange "-L+" prefix. They are built without the complete path - as before, when I tried several things together with Arjen - but this is no wonder and does not have any negative effect on the final compilation. @Arjen: It seems to me, as if the D-branch of the CMake modules has some strange side effects. Is there anything I should try? -- Best regards, Thorsten |
From: Alan W. I. <ir...@be...> - 2014-04-04 16:34:48
|
On 2014-04-04 17:27+0200 Thorsten Behrens wrote: > Hi Phil! > >> I remember finding some similar linker issue on my Windows system. My >> memory is telling me it was a lower case l that was prepended, but it >> might have been the same thing as you. I just tried to find my posts to >> the list to confirm either way, but I can't find them. From memory it >> seemed almost like a buffer overrun thing. I spent some time adding >> debug output to try to find where it got appended and it was related to >> checking for D, but I like you haven't got a D compiler. Explicitly >> adding -DENABLE_d=OFF to my command line fixed the problem for me. > > Astonishment!!! > > I ran CMake again building PLplot, but this time with -DENABLE_d=OFF added > to the command line. Now, all the linker input directives are given > correctly, i.e. without this strange "-L+" prefix. They are built without > the complete path - as before, when I tried several things together with > Arjen - but this is no wonder and does not have any negative effect on the > final compilation. > > @Arjen: > It seems to me, as if the D-branch of the CMake modules has some strange > side effects. Is there anything I should try? I don't think we should fiddle with the D language support for now. The reason is language support under CMake is badly documented so it takes quite an effort to get it right, and in any case that D support code was imported from another group's efforts so nobody here understands it. Instead, what I have decided to do (revision 13095) is to set -DENABLE_d=OFF as the default on Windows. Furthermore, if a Windows users goes out of their way to specify -DENABLE_d=ON they will be warned of the conflict with wxwidgets. I hope everyone is satisified with that semi-permanent workaround to the interference on Windows between D language support and wxwidgets linking. Thanks, Thorsten, for reminding us of this issue which we had not paid enough attention to until now. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-04 16:09:54
|
On 2014-04-04 08:10-0700 phil rosenberg wrote: > Hi Thorsten > I remember finding some similar linker issue on my Windows system. My memory is telling me it was a lower case l that was prepended, but it might have been the same thing as you. I just tried to find my posts to the list to confirm either way, but I can't find them. From memory it seemed almost like a buffer overrun thing. I spent some time adding debug output to try to find where it got appended and it was related to checking for D, but I like you haven't got a D compiler. Explicitly adding -DENABLE_d=OFF to my command line fixed the problem for me. Hi Phil: Thanks for participating in this thread. Our mails crossed, but now you have reminded me of this previous thread my memory agrees with yours of what previously worked for you. Thus, I agree -DENABLE_d=OFF will likely solve the issue for Thorsten. (The proper fix for this is to modify our D language support so it does not interfere on Windows, but language support is really tricky so I am going to put that off indefinitely.) Anticipating that Thorsten reports back that -DENABLE_d=OFF solves the issue, then I will change our build system so that -DENABLE_d=OFF is the default on Windows. Also, in this case no further changes will be needed for cmake/modules/FindwxWidgets.cmake. That still leaves my question to you concerning the status of getting our version of that find module propagated upstream to CMake. 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 __________________________ |
From: phil r. <phi...@ya...> - 2014-04-05 09:00:42
|
Hi Alan From memory it was the actual call to enable_language(D OPTIONAL) that caused the problem. I had wondered if I had reported a bug to Cmake, but I just checked and I hadn't. Thorsten - if you have the debug message calls set up and it is easy for you to check if this is the same issue and if Alan can confirm that this isn't related to the Plplot CMake code then maybe you might want to report it Regarding wxWidgets - unfortunately no my intention was not to volunteer to become the maintainer. I already have a backlog of Plplot things I want to deal with that I'm struggling to find time for. Adding a extra commitment just isn't possible for me. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: "plp...@li..." <plp...@li...>; "tho...@do..." <tho...@do...> Sent: Friday, 4 April 2014, 17:09 Subject: Re: [Plplot-devel] Wrong linker directives for Visual Studio 2010 On 2014-04-04 08:10-0700 phil rosenberg wrote: > Hi Thorsten > I remember finding some similar linker issue on my Windows system. My memory is telling me it was a lower case l that was prepended, but it might have been the same thing as you. I just tried to find my posts to the list to confirm either way, but I can't find them. From memory it seemed almost like a buffer overrun thing. I spent some time adding debug output to try to find where it got appended and it was related to checking for D, but I like you haven't got a D compiler. Explicitly adding -DENABLE_d=OFF to my command line fixed the problem for me. Hi Phil: Thanks for participating in this thread. Our mails crossed, but now you have reminded me of this previous thread my memory agrees with yours of what previously worked for you. Thus, I agree -DENABLE_d=OFF will likely solve the issue for Thorsten. (The proper fix for this is to modify our D language support so it does not interfere on Windows, but language support is really tricky so I am going to put that off indefinitely.) Anticipating that Thorsten reports back that -DENABLE_d=OFF solves the issue, then I will change our build system so that -DENABLE_d=OFF is the default on Windows. Also, in this case no further changes will be needed for cmake/modules/FindwxWidgets.cmake. That still leaves my question to you concerning the status of getting our version of that find module propagated upstream to CMake. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-05 15:52:11
|
On 2014-04-05 02:00-0700 phil rosenberg wrote: > Hi Alan > From memory it was the actual call to enable_language(D OPTIONAL) that caused the problem. I had wondered if I had reported a bug to Cmake, but I just checked and I hadn't. > Thorsten - if you have the debug message calls set up and it is easy for you to check if this is the same issue and if Alan can confirm that this isn't related to the Plplot CMake code then maybe you might want to report it Actually, this bug is most likely our responsibility since we implement the D language support ourselves. See the D-related files in cmake/modules/language_support/cmake/ and cmake/modules/language_support/cmake/Platform (which we have copied from 3rd party sources who don't support them any more). Also, I do not see this issue for MinGW/MSYS so it is probably due to some weird interaction between our D language support, the find module for wxwidgets (also our responsibility although the modifications from the official CMake module are pretty small), and the Visual Studio type generators that you and Thorsten are using. So for this and the other reasons I mentioned, this is going to be a really difficult bug to deal with so I am putting off that effort indefinitely and instead working around the issue by using a default of -DENABLE_d=OFF for the Windows case. (I considered only specifying that OFF default for just the Visual Studio type of generators, but there is very little call for D language support on Windows, and I don't really have a clue about what exactly is going on so I am applying that broader workaround for now.) > Regarding wxWidgets - unfortunately no my intention was not to volunteer to become the maintainer. I already have a backlog of Plplot things I want to deal with that I'm struggling to find time for. Adding a extra commitment just isn't possible for me. Fair enough. That makes it somewhat more difficult to convince Brad King to accept your changes for the official version of the wxwidgets find module, but meanwhile others do have access to your work on the find module via your CMake bug report. 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 __________________________ |
From: Arjen M. <Arj...@de...> - 2014-04-06 17:30:10
|
Hi Alan, Thorsten, > -----Original Message----- ... Also, I do not see this issue for > MinGW/MSYS so it is probably due to some weird interaction between our D > language support, the find module for wxwidgets (also our responsibility although > the modifications from the official CMake module are pretty small), and the Visual > Studio type generators that you and Thorsten are using. So for this and the other > reasons I mentioned, this is going to be a really difficult bug to deal with so I am > putting off that effort indefinitely and instead working around the issue by using a > default of -DENABLE_d=OFF for the Windows case. (I considered only specifying > that OFF default for just the Visual Studio type of generators, but there is very little > call for D language support on Windows, and I don't really have a clue about what > exactly is going on so I am applying that broader workaround for now.) > Well, the workaround is definitely simpler than adding the logic to handle exactly this build case. I had a look at the other SDK versions I have on my machine - 8.0 and 8.0A - they have a completely different content, so they probably have a different purpose altogether. Well, the workaround by turning off the D language makes it easier: we can ignore these issues. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Thorsten B. <tho...@do...> - 2014-04-07 15:12:05
|
Hi! Sorry, for my late reply, but I wasn't "available" over the weekend. >> ... Also, I do not see this issue for MinGW/MSYS so it is probably >> due to some weird interaction between our D language support, the >> find module for wxwidgets (also our responsibility although the >> modifications from the official CMake module are pretty small), and the >> Visual Studio type generators that you and Thorsten are using. This issue is indeed somewhat strange, and I haven't really found the exact background of the side effects, but I was able to track it down a bit further. The general cause of all trouble is within the file CMakeDInformation.cmake (which is burried deep inside the path \cmake\modules\language_support\cmake). As far as I understand it, this module is intended to define several CMake variables/properties for the different environments the project might be built under. In lines 178-204 some variables/properties regarding OS and D compiler used are set up. *Only* if the OS is Windows and the compiler is not GDC, then CMAKE_LINK_LIBRARY_FLAG is set to "-L+"). Now, I don't know which compiler/linker environment uses this special prefix to introduce an additionally linked in library, but if we are able to find out, which one this is, we could just guard this assignment with an if-statement and everything should be fine. This might be much easier than trying to find the reason why everything is fine too, if I add an explicit path to the libraries needed for wxWidgets (line 447 of FindwxWidgets.cmake). This must be due a strange side effect when evaluating library related variables and setting up the built environment by CMake. I have built PLplot with the following command lines 1) cmake -G "Visual Studio 10" <path-to-PLplot-source> 2) cmake -G "Visual Studio 10" -DENABLE_d=OFF <path-to-PLplot-source> 3) cmake -G "Visual Studio 10" -DBUILD_TEST=OFF <path-to-PLplot-source> 4) cmake -G "Visual Studio 10" -DBUILD_TEST=ON <path-to-PLplot-source> 5) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=OFF <path-to-PLplot-source> 6) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=ON <path-to-PLplot-source> 7) cmake -G "Visual Studio 10" -DBUILD_TEST=ON -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> 8) cmake -G "Visual Studio 10" -DBUILD_TEST=OFF -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> 9) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=OFF -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> 10) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=ON -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> and all of these compile find as soon as I just change that given line in CMakeDInformation.cmake (line 193) into a comment. Something else strikes me odd with this CMAKE_LINK_LIBRARY_FLAG variable. Most other variables being set in that block of code contain an explicit reference to the D language ... and because of this most probably do not interfere with other languages. Only the variables CMAKE_LINK_LIBRARY_FLAG, CMAKE_LIBRARY_PATH_FLAG and CMAKE_LIBRARY_PATH_TERMINATOR do not refer specifically to the D language. Perhaps, when introducing language support for D, it was forgotten to make these variables language dependent? In a next step I will look at the history of CMakeDInformation.cmake (if that is available in the archives) and try to understand why this might have been added here. Perhaps this gives a better insight on the issue. >> So for this and the other reasons I mentioned, this is going to be >> a really difficult bug to deal with so I am putting off that effort >> indefinitely and instead working around the issue by using a >> default of -DENABLE_d=OFF for the Windows case. (I considered only >> specifying that OFF default for just the Visual Studio type of >> generators, but there is very little call for D language support on >> Windows, and I don't really have a clue about what exactly is going >> on so I am applying that broader workaround for now.) > > Well, the workaround is definitely simpler than adding the logic to > handle exactly this build case. I had a look at the other SDK > versions I have on my machine - 8.0 and 8.0A - they have a completely > different content, so they probably have a different purpose > altogether. Well, the workaround by turning off the D language makes > it easier: we can ignore these issues. I agree with you, that it is indeed quite easy to just use a big hammer for this small nail, but this might cause bigger problems for whoever needs PLplot using the D language. The SDK versions of the libraries used by the wxWidget-modules are in my eyes just another kettle of fish ... unluckily these interfere with just the D language support. For whatever reason some functions were needed by wxWidgets and whoever needed these functions found them in the libraries comctl32.lib and rpcrt4.lib of this SDK. In a next step I will try to find out which functions calls are missing, if these libraries are not present. Perhaps these have just moved to other libraries in newer versions of the SDK. -- Best regards, Thorsten |
From: Alan W. I. <ir...@be...> - 2014-04-07 16:21:55
|
On 2014-04-07 17:11+0200 Thorsten Behrens wrote: > [...]The general cause of all trouble is within the file > CMakeDInformation.cmake (which is burried deep inside the path > \cmake\modules\language_support\cmake). Agreed. > > As far as I understand it, this module is intended to define several CMake > variables/properties for the different environments the project might be > built under. In lines 178-204 some variables/properties regarding OS and D > compiler used are set up. *Only* if the OS is Windows and the compiler is > not GDC, then CMAKE_LINK_LIBRARY_FLAG is set to "-L+"). and possibly SET(CMAKE_LIBRARY_PATH_FLAG "-L+") causes problems as well. > [...]Something else strikes me odd with this CMAKE_LINK_LIBRARY_FLAG variable. > Most other variables being set in that block of code contain an explicit > reference to the D language ... and because of this most probably do not > interfere with other languages. Only the variables > CMAKE_LINK_LIBRARY_FLAG, CMAKE_LIBRARY_PATH_FLAG and > CMAKE_LIBRARY_PATH_TERMINATOR do not refer specifically to the D language. > Perhaps, when introducing language support for D, it was forgotten to make > these variables language dependent? No, these variables are also set in official CMake language support files as well. But the way they are set is much more generic and compiler- and platform-dependent rather than computer-language dependent. This is because CMake language support has become much more sophisticated since the early history of CMake when CMakeDInformation.cmake was implemented by a non-CMake group of developers. Furthermore, there is no mention of the -L+ flag in _any_ of the official methods where the above variables are set so either that was a mistake by the implementers of CMakeDInformation.cmake or only valid for an extremely narrow set of circumstances. For example, if http://msdn.microsoft.com/en-us/library/windows/hardware/ff552114(v=vs.85).aspx is relevant documentation for this compiler option it does appear to be specific to "control source display and program stepping options" so nothing to do with linking and thus likely a mistake for Windows platforms. > I agree with you, that it is indeed quite easy to just use a big hammer > for this small nail, but this might cause bigger problems for whoever > needs PLplot using the D language. No, this workaround does not affect D language support on Unix which by and large works without issues. It only affects those using the D language on Windows. Furthermore, to my knowledge nobody has tried that combination yet. So by definition that is an experimental combination where setting -DENABLE_d=OFF by default (but allowing the user to set -DENABLE_d=ON if they so desire) is the correct approach in my view. Thorsten (or anybody else here) if you do have access to a D compiler on Windows and want to look further into D language support on that platform, I would encourage you to experiment with Windows-only changes to our D language support files (using -DENABLE_d=ON), but otherwise I don't think it is possible to figure out what changes are needed in those files for the Windows case. 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 __________________________ |
From: Thorsten B. <tho...@do...> - 2014-04-08 08:45:48
|
Hi Alan! >> CMake variables/properties for the different environments the >> project might be built under. In lines 178-204 some >> variables/properties regarding OS and D compiler used are set >> up. *Only* if the OS is Windows and the compiler is not GDC, >> then CMAKE_LINK_LIBRARY_FLAG is set to "-L+"). > > and possibly SET(CMAKE_LIBRARY_PATH_FLAG "-L+") causes problems as well. No, I've tried that as well in my tests. This variable seems to have no influence on the generated build files for Visual Studio. > ... > Furthermore, there is no mention of the -L+ flag in _any_ of the > official methods where the above variables are set so either that was > a mistake by the implementers of CMakeDInformation.cmake or only valid > for an extremely narrow set of circumstances. For example, if > http://msdn.microsoft.com/en-us/library/windows/hardware/ff552114(v=vs.85).aspx > is relevant documentation for this compiler option it does appear to > be specific to "control source display and program stepping options" > so nothing to do with linking and thus likely a mistake for > Windows platforms. The Microsoft Website mentioned above has nothing to do with our problem. It is a reference for WinDbg, a debugger, and the command described there just resembles the -L+ flag. But, on http://www.dsource.org/projects/visuald/ticket/45 the option(s) "-L-L+" are at least mentioned and this page refers to the programming language D. > Thorsten (or anybody else here) if you do have access to a D compiler > on Windows and want to look further into D language support on that > platform, I would encourage you to experiment with Windows-only > changes to our D language support files (using -DENABLE_d=ON), but > otherwise I don't think it is possible to figure out what changes are > needed in those files for the Windows case. I will give this a try today. According to the CMakeDInformation two compilers seem of interest, DMD and GDC. Because the erroneous linker flag is in the non-GDC branch, I will do my tests using DMD. -- Gruß, Thorsten |
From: Alan W. I. <ir...@be...> - 2014-04-08 16:41:02
|
On 2014-04-08 10:45+0200 Thorsten Behrens wrote: > Hi Alan! > [Alan said:] >> Thorsten (or anybody else here) if you do have access to a D compiler >> on Windows and want to look further into D language support on that >> platform, I would encourage you to experiment with Windows-only >> changes to our D language support files (using -DENABLE_d=ON), but >> otherwise I don't think it is possible to figure out what changes are >> needed in those files for the Windows case. > > I will give this a try today. According to the CMakeDInformation two > compilers seem of interest, DMD and GDC. Because the erroneous linker flag > is in the non-GDC branch, I will do my tests using DMD. That would be great. By the way, I agree with you the present logic for setting general non-D variables (that affect all compilers) such as CMAKE_LIBRARY_PATH_FLAG, CMAKE_LIBRARY_PATH_FLAG, and CMAKE_LIBRARY_PATH_TERMINATOR cannot be correct. The present overall logic for doing that is IF(CMAKE_COMPILER_IS_GDC # Set D-related variables [...] # Set general variables [...] ELSE(CMAKE_COMPILER_IS_GDC) IF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows") # Set D-related variables [...] # Set general variables [...] ELSE(${CMAKE_SYSTEM_NAME} STREQUAL "Windows") # Set D-related variables [...] # Set general variables [...] ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows") ENDIF(CMAKE_COMPILER_IS_GDC) One of the problem (as I see it) is that ELSE(CMAKE_COMPILER_IS_GDC) clause which means every compiler is affected (as you found out) by whatever is set for the general variables for the non-GDC case. I would suggest replacing that clause by ELSEIF(CMAKE_COMPILER_IS_DMD) as an experiment to see whether that stops the cross-talk with the other compilers. Of course, that change has nothing to do with the variables that need to be set to get DMD to work in the Windows case so additional experiments will likely be required to get that working. By the way, I don't think the DMD compiler support has been tested on any platform yet. According to http://en.wikipedia.org/wiki/D_(programming_language), DMD is not completely open source software. Thus, Debian (and presumably most other Linux distributions) aren't allowed to distribute it. So all our testing so far of the D binding for PLplot has been done with GDC. Also, I don't think GDC has been tested on the Windows platform so if you get a chance to do such testing as well as the DMD testing you have planned, that would be great. 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 __________________________ |
From: Thorsten B. <tho...@do...> - 2014-04-08 15:28:20
|
Hi Alan! >> Thorsten (or anybody else here) if you do have access to a D compiler >> on Windows and want to look further into D language support on that >> platform, I would encourage you to experiment with Windows-only >> changes to our D language support files (using -DENABLE_d=ON), but >> otherwise I don't think it is possible to figure out what changes are >> needed in those files for the Windows case. > > I will give this a try today. According to the CMakeDInformation two > compilers seem of interest, DMD and GDC. Because the erroneous linker > flag is in the non-GDC branch, I will do my tests using DMD. I installed DMD 2.065.0 and did the following tests using the latest version of PLplot (Rev. 13100) with just one exception. This exception is a change in FindwxWdigets.cmake. I removed the obviously unused libraries winmm.lib and wsock32.lib 1) cmake -G "Visual Studio 10" <path-to-plplot-src> This was just to test that D will not be enabled (due to -DENABLE_d=OFF being the default setting) although it is installed on the system. This build was fine. No tests have been installed, wxWidgets has been found and all projects could be compiled with VS 10. 2) cmake -G "Visual Studio 10" -DENABLE_d=ON -DENABLE_wxwidgets=OFF <path-to-plplot-src> This was to test whether just D itself will be recognized. I disabled wxWidgets here to suppress any might-be interference between D and wxWidgets. I wasn't able to complete this test. All the day I fiddled around with CMake, but whatever I changed within \cmake\modules\language_support\cmake\CMakeD*.cmake CMake never recognized a working D compiler. I have no problems compiling, linking and running any D example programs from the net. Thus, D itself is correctly installed and working. Whenever using CMake, however, it fails in \cmake\modules\language_support.cmake when trying to compile a simple test program. This test program is defined inline in CMakeTestDCompiler.cmake (lines 24-25). Copying this into a file and compiling it directly from the D command shell works like a charm. So, the test program itself is also OK. CMake complains as follows: ---snip--- -- The C compiler identification is MSVC 16.0.40219.1 -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMAKE_GENERATOR = Visual Studio 10 -- D Compiler Install Prefix (use D_PATH env var to override): F:/D/dmd2/windows -- Check for working D compiler: F:/D/dmd2/windows/bin/dmd.exe -- Check for working D compiler: F:/D/dmd2/windows/bin/dmd.exe -- broken CMake Error at I:/PLplot/PLplot-5.10.0/cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:52 (MESSAGE): The D compiler "F:/D/dmd2/windows/bin/dmd.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe cmTryCompileExec2509696440.vcxproj /p:Configuration=Debug /p:VisualStudioVersion=10.0 Microsoft (R)-Buildmodul, Version 4.0.30319.18408 [Microsoft .NET Framework, Version 4.0.30319.18444] Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Der Buildvorgang wurde am 08.04.2014 16:51:37 gestartet. Projekt "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj" auf Knoten "1" (Standardziele). PrepareForBuild: Das Verzeichnis "cmTryCompileExec2509696440.dir\Debug\" wird erstellt. Das Verzeichnis "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\" wird erstellt. InitializeBuildStatus: "cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.unsuccessfulbuild" wird erstellt, da "AlwaysCreate" angegeben wurde. ManifestResourceCompile: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo /fo"cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.embed.manifest.res" cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440_manifest.rc Link: F:\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe" /INCREMENTAL /NOLOGO /MANIFEST /ManifestFile:"cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:"I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec2509696440.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec2509696440.lib" /MACHINE:X86 cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.embed.manifest.res LINK : error LNK2001: Nicht aufgelöstes externes Symbol "_mainCRTStartup". [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe : fatal error LNK1120: 1 nicht aufgelöste externe Verweise. [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] Die Erstellung des Projekts "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER. Fehler beim Buildvorgang. "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj" (Standardziel) (1) -> (Link Ziel) -> LINK : error LNK2001: Nicht aufgelöstes externes Symbol "_mainCRTStartup". [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe : fatal error LNK1120: 1 nicht aufgelöste externe Verweise. [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] 0 Warnung(en) 2 Fehler Verstrichene Zeit 00:00:00.69 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:33 (enable_language) ---snap--- According to the CMake FAQ I should use the WIN32 argument to ADD_EXECUTABLE. This, however, is not possible, as enable_language generates its own CMake.txt file on the fly (that obviously contains some ADD_EXECUTABLE line). I then tried to set several CMake variables (all I found in CMake's online documentation that may have some influence on the linker) just before the TRY_COMPILE in line 29 of CMakeTestDCompiler.cmake, but all to no avail. I noticed a similar error when trying to enable Fortran and Ada (but normally I have these disabled - I wanted to try Ada at some later stage), so this may be points to a general problem using other languages under Windows and using Visual Studio generators. Has anyone any ideas on this topic? -- Best regards, Thorsten |
From: Alan W. I. <ir...@be...> - 2014-04-08 18:44:08
|
On 2014-04-08 17:28+0200 Thorsten Behrens wrote: > Hi Alan! > >>> Thorsten (or anybody else here) if you do have access to a D compiler >>> on Windows and want to look further into D language support on that >>> platform, I would encourage you to experiment with Windows-only >>> changes to our D language support files (using -DENABLE_d=ON), but >>> otherwise I don't think it is possible to figure out what changes are >>> needed in those files for the Windows case. >> >> I will give this a try today. According to the CMakeDInformation two >> compilers seem of interest, DMD and GDC. Because the erroneous linker >> flag is in the non-GDC branch, I will do my tests using DMD. > > I installed DMD 2.065.0 and did the following tests using the latest > version of PLplot (Rev. 13100) with just one exception. This exception is > a change in FindwxWdigets.cmake. I removed the obviously unused libraries > winmm.lib and wsock32.lib > > 1) cmake -G "Visual Studio 10" <path-to-plplot-src> > This was just to test that D will not be enabled (due to -DENABLE_d=OFF > being the default setting) although it is installed on the system. This > build was fine. No tests have been installed, wxWidgets has been found and > all projects could be compiled with VS 10. > > 2) cmake -G "Visual Studio 10" -DENABLE_d=ON -DENABLE_wxwidgets=OFF > <path-to-plplot-src> > This was to test whether just D itself will be recognized. I disabled > wxWidgets here to suppress any might-be interference between D and > wxWidgets. > > I wasn't able to complete this test. All the day I fiddled around with > CMake, but whatever I changed within > \cmake\modules\language_support\cmake\CMakeD*.cmake CMake never recognized > a working D compiler. > > I have no problems compiling, linking and running any D example programs > from the net. Thus, D itself is correctly installed and working. > > Whenever using CMake, however, it fails in > \cmake\modules\language_support.cmake when trying to compile a simple test > program. This test program is defined inline in CMakeTestDCompiler.cmake > (lines 24-25). Copying this into a file and compiling it directly from the > D command shell works like a charm. So, the test program itself is also OK. > > CMake complains as follows: > ---snip--- > -- The C compiler identification is MSVC 16.0.40219.1 > -- Check for working C compiler using: Visual Studio 10 > -- Check for working C compiler using: Visual Studio 10 -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- CMAKE_GENERATOR = Visual Studio 10 > -- D Compiler Install Prefix (use D_PATH env var to override): > F:/D/dmd2/windows > -- Check for working D compiler: F:/D/dmd2/windows/bin/dmd.exe > -- Check for working D compiler: F:/D/dmd2/windows/bin/dmd.exe -- broken > > CMake Error at > I:/PLplot/PLplot-5.10.0/cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:52 > (MESSAGE): > The D compiler "F:/D/dmd2/windows/bin/dmd.exe" is not able to compile a > simple test program. > > It fails with the following output: > > Change Dir: I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp > > Run Build > Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe > cmTryCompileExec2509696440.vcxproj /p:Configuration=Debug > /p:VisualStudioVersion=10.0 > > Microsoft (R)-Buildmodul, Version 4.0.30319.18408 > > [Microsoft .NET Framework, Version 4.0.30319.18444] > > Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. > > Der Buildvorgang wurde am 08.04.2014 16:51:37 gestartet. > > Projekt > "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj" > auf Knoten "1" (Standardziele). > > PrepareForBuild: > > Das Verzeichnis "cmTryCompileExec2509696440.dir\Debug\" wird erstellt. > Das Verzeichnis > "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\" wird > erstellt. > > InitializeBuildStatus: > > "cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.unsuccessfulbuild" > wird erstellt, da "AlwaysCreate" angegeben wurde. > > ManifestResourceCompile: > > C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo > /fo"cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.embed.manifest.res" > cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440_manifest.rc > > Link: > > F:\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPORT:QUEUE > /OUT:"I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe" > /INCREMENTAL /NOLOGO /MANIFEST > /ManifestFile:"cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.intermediate.manifest" > /MANIFESTUAC:"level='asInvoker' uiAccess='false'" > /PDB:"I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec2509696440.pdb" > /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT > /IMPLIB:"I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec2509696440.lib" > /MACHINE:X86 > cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.embed.manifest.res > > LINK : error LNK2001: Nicht aufgelöstes externes Symbol > "_mainCRTStartup". > [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] > > I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe > : fatal error LNK1120: 1 nicht aufgelöste externe Verweise. > [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] > > Die Erstellung des Projekts > "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj" > ist abgeschlossen (Standardziele) -- FEHLER. > > Fehler beim Buildvorgang. > > "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj" > (Standardziel) (1) -> > (Link Ziel) -> > > LINK : error LNK2001: Nicht aufgelöstes externes Symbol > "_mainCRTStartup". > [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] > > I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe > : fatal error LNK1120: 1 nicht aufgelöste externe Verweise. > [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj] > > 0 Warnung(en) > 2 Fehler > > Verstrichene Zeit 00:00:00.69 > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:33 (enable_language) > ---snap--- > > According to the CMake FAQ I should use the WIN32 argument to > ADD_EXECUTABLE. This, however, is not possible, as enable_language > generates its own CMake.txt file on the fly (that obviously contains some > ADD_EXECUTABLE line). I then tried to set several CMake variables (all I > found in CMake's online documentation that may have some influence on the > linker) just before the TRY_COMPILE in line 29 of > CMakeTestDCompiler.cmake, but all to no avail. > > I noticed a similar error when trying to enable Fortran and Ada (but > normally I have these disabled - I wanted to try Ada at some later stage), > so this may be points to a general problem using other languages under > Windows and using Visual Studio generators. > > Has anyone any ideas on this topic? Greatly simplify your test case to make it easier for others to test the problem and to remove most of PLplot from the question. To do that create a new source tree containing just the single file CMakeLists.txt and the language support tree cmake/modules/language_support/cmake (including all subdirectories) copied from PLplot. That CMakeLists.txt file should contain the following: cmake_minimum_required(VERSION 2.8.12.2 FATAL_ERROR) project(test_d D) # Get access to D language support set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake) Since gdc is the debugged D compiler on the Linux side, I would first try the above simple test case for that compiler rather than dmd. I would also use the nmake generator since that is likely more free of bugs than the complicated generator you are using. Another important cmake debugging tip when try compiles are going wrong (from the cmake man page): --debug-trycompile Do not delete the try_compile build tree. Only useful on one try_compile at a time. Do not delete the files and directories created for try_compile calls. This is useful in debugging failed try_compiles. It may however change the results of the try-compiles as old junk from a previous try-compile may cause a different test to either pass or fail incorrectly. This option is best used for one try-compile at a time, and only when debugging. This should help you figure out exactly what command-line command is going wrong for the simple try compile case, and thus supply the result for whatever change you make to the files in cmake/modules/language_support/cmake. If these tips help you to figure out bug fixes for the D language support on Windows platforms, I would be very happy to apply your patch. 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 __________________________ |