From: phil r. <phi...@ya...> - 2014-08-28 17:06:50
|
Hi Alan I have done my best to look at this, but I am struggling. Looking at the various tcl related variables they all appear at first glance to be fine. I have just tried literally outputting every variable at the end of the top level cmakelists.txt. Looking through I notices that the ntk_COMPILE_FLAGS variable, and in fact all the tcl related paths are surrounded by single quotes, whereas the wxwidgets_COMPILE_FLAGS variable is not: -- wxwidgets_COMPILE_FLAGS = -ID:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_lib/mswud -ID:/SourceCode/Libraries/wxWidgets-3.0.0/include -DUNICODE -D_UNICODE -- ntk_COMPILE_FLAGS='-IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include' Would this make any difference to how CMake deals with them? Beyond that I am well out of my depth Phil From: phil rosenberg <phi...@ya...> To: P Lplot development list <plp...@li...> Sent: Wednesday, 27 August 2014, 22:32 Subject: tcl build problem Hi all, but mostly Alan as our Cmake expert I've just installed tcl and it is causing me some plplot build problems. I have installed tcl to C:\Program Files\tcl, giving an include path of C:\Program Files\tcl\include, this appears to be the problem. Somehow in dealing with this path it is getting separated at the space. This means that the command line adds the include directory C:\Program. This is followed with a number of other parameters and Files\tcl\include gets stuck on the end of command lines, which gets interpreted as a file to compile, which obviously can't be found. Alan, I can try and have a look at this, but I haven't much time as I'm trying to spend my plplot time looking at the exit calls. I thought you might know where to look. Phil |
From: Phil R. <phi...@ya...> - 2014-08-28 19:34:42
|
Hi Alan Given what you said I did a quick google for cmake paths spaces and immediately found this post http://stackoverflow.com/questions/9964775/using-cmakes-include-directories-command-with-white-spaces. Seems the issue is the same there and is a result of the find modules assuming no whitespace. I'll see if I can work out where the quotes should go and if not then I'll uninstall and reinstall tcl I guess. -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 28/08/2014 19:12 To: "phil rosenberg" <phi...@ya...> Cc: "PLplot development list" <plp...@li...> Subject: Re: [Plplot-devel] tcl build problem On 2014-08-28 10:06-0700 phil rosenberg wrote: > Hi Alan > I have done my best to look at this, but I am struggling. Looking at the various tcl related variables they all appear at first glance to be fine. I have just tried literally outputting every variable at the end of the top level cmakelists.txt. Looking through I notices that the ntk_COMPILE_FLAGS variable, and in fact all the tcl related paths are surrounded by single quotes, whereas the wxwidgets_COMPILE_FLAGS variable is not: > > -- wxwidgets_COMPILE_FLAGS = -ID:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_lib/mswud -ID:/SourceCode/Libraries/wxWidgets-3.0.0/include -DUNICODE -D_UNICODE > -- ntk_COMPILE_FLAGS='-IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include' > > > Would this make any difference to how CMake deals with them? The above information is incomplete because it simply states how CMake views these variables. That is important information, but to see the exact effect of those variables you should be invoking nmake like nmake VERBOSE=1 <target_name> and capturing the resulting output as well for the case where something is built with the relevant -I option. > Beyond that I am well out of my depth Frankly, I am out of my depth as well with regard to how blanks in path names affect our build system because we so rarely test that case. Years ago I tried to pursue this issue on Linux by deliberately using some paths with blanks in them. The result was I could get a very limited PLplot build to work, but anything larger (such as adding Tcl) always failed for reasons I didn't completely understand. My advice (which echos the advice of most free software projects about this issue) is simply avoid the issue. That is always use a source tree, build tree, and install tree without blanks in the path, and similarly for all packages that PLplot depends on. Of course, that means when you install Tcl, you have to be careful about specifying the install prefix without a blank in the name of that path because the default path (e.g., C:/Program Files above) does have a blank in it which is the source of your present difficulties. For example, I would suggest using C:/Program_Files instead for the installation prefix, and then set the appropriate environment variables (such as CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH) so that cmake always finds that non-blank named version. 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-08-28 20:29:30
|
On 2014-08-28 20:33+0100 Phil Rosenberg wrote: > Hi Alan > Given what you said I did a quick google for cmake paths spaces and immediately found this post http://stackoverflow.com/questions/9964775/using-cmakes-include-directories-command-with-white-spaces. Seems the issue is the same there and is a result of the find modules assuming no whitespace. I'll see if I can work out where the quotes should go and if not then I'll uninstall and reinstall tcl I guess. Hi Phil: I mostly agree with everything I read at that stackoverflow site but compile flags are a special case where the result must be a blank delimited string (as opposed to a CMake list). Looking further (in cmake/modules/tk.cmake) the culprit appears to be the command set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}") (where it just happens -I${TCL_INCLUDE_PATH} and ${TKLIB_COMPILE_FLAGS} refer to the same thing on your system, but on other systems they can be different and the repeat duplicate -I options should not be an issue on your system. When faced with CMake logic issues, it is always a good idea to make a few-line file to test out possibilities. In this case my test file (test.cmake) reads # Note the quotes which keep TCL_INCLUDE_PATH and TKLIB_COMPILE_FLAGS # from being lists. I think these represent the CMake variables # exactly on your system. set(TCL_INCLUDE_PATH "C:/Program Files/Tcl/include") set(TKLIB_COMPILE_FLAGS "-IC:/Program Files/Tcl/include") #Wrong (as currently the case in cmake/modules/tk.cmake) set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}") message(STATUS "wrong ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}") #Right (I hope) set(ntk_COMPILE_FLAGS "\"-I${TCL_INCLUDE_PATH}\" \"${TKLIB_COMPILE_FLAGS}\"") message(STATUS "right ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}") and you run it like this: irwin@raven> cmake -P test.cmake -- wrong ntk_COMPILE_FLAGS = -IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include -- right ntk_COMPILE_FLAGS = "-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include" I suggest you change cmake/modules/tk.cmake to conform to the second form, and then observe (via the VERBOSE=1 option on nmake) the resulting build command. My hope is that one string with blank-separated entities that are themselves quoted using escaped quotes (the "right" version above) will force CMake to generate compile options of either "-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include" or -IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include But let me know what the VERBOSE=1 nmake option tells you about the actual build command that results from the above change. 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-08-28 23:18:14
|
Hi Alan I found the same location in the file you specified between checking emails. I have been through and added the \" where appropriate to the various (rpath, compile, linker) flags. This allows me to compile, but I am getting linker errors in the examples, because the linker flags are ending up as "C:/Program Files/Tcl/lib/tcl86.lib".lib I'm not sure where the extra .lib is appearing from. If I fix this manually I then get further linker errors which seem to be name decoration static vs dynamic library issues. I will have to figure those out on my system. ________________________________ From: Alan W. Irwin <ir...@be...> To: Phil Rosenberg <phi...@ya...> Cc: PLplot development list <plp...@li...> Sent: Thursday, 28 August 2014, 21:29 Subject: RE: [Plplot-devel] tcl build problem On 2014-08-28 20:33+0100 Phil Rosenberg wrote: > Hi Alan > Given what you said I did a quick google for cmake paths spaces and immediately found this post http://stackoverflow.com/questions/9964775/using-cmakes-include-directories-command-with-white-spaces. Seems the issue is the same there and is a result of the find modules assuming no whitespace. I'll see if I can work out where the quotes should go and if not then I'll uninstall and reinstall tcl I guess. Hi Phil: I mostly agree with everything I read at that stackoverflow site but compile flags are a special case where the result must be a blank delimited string (as opposed to a CMake list). Looking further (in cmake/modules/tk.cmake) the culprit appears to be the command set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}") (where it just happens -I${TCL_INCLUDE_PATH} and ${TKLIB_COMPILE_FLAGS} refer to the same thing on your system, but on other systems they can be different and the repeat duplicate -I options should not be an issue on your system. When faced with CMake logic issues, it is always a good idea to make a few-line file to test out possibilities. In this case my test file (test.cmake) reads # Note the quotes which keep TCL_INCLUDE_PATH and TKLIB_COMPILE_FLAGS # from being lists. I think these represent the CMake variables # exactly on your system. set(TCL_INCLUDE_PATH "C:/Program Files/Tcl/include") set(TKLIB_COMPILE_FLAGS "-IC:/Program Files/Tcl/include") #Wrong (as currently the case in cmake/modules/tk.cmake) set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}") message(STATUS "wrong ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}") #Right (I hope) set(ntk_COMPILE_FLAGS "\"-I${TCL_INCLUDE_PATH}\" \"${TKLIB_COMPILE_FLAGS}\"") message(STATUS "right ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}") and you run it like this: irwin@raven> cmake -P test.cmake -- wrong ntk_COMPILE_FLAGS = -IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include -- right ntk_COMPILE_FLAGS = "-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include" I suggest you change cmake/modules/tk.cmake to conform to the second form, and then observe (via the VERBOSE=1 option on nmake) the resulting build command. My hope is that one string with blank-separated entities that are themselves quoted using escaped quotes (the "right" version above) will force CMake to generate compile options of either "-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include" or -IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include But let me know what the VERBOSE=1 nmake option tells you about the actual build command that results from the above change. 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-08-29 00:07:54
|
On 2014-08-28 16:18-0700 phil rosenberg wrote: > Hi Alan > I found the same location in the file you specified between checking emails. I have been through and added the \" where appropriate to the various (rpath, compile, linker) flags. This allows me to compile, but I am getting linker errors in the examples, because the linker flags are ending up as > "C:/Program Files/Tcl/lib/tcl86.lib".lib > I'm not sure where the extra .lib is appearing from. If I fix this manually I then get further linker errors which seem to be name decoration static vs dynamic library issues. I will have to figure those out on my system. There may also be non-blank build-system issues for Tcl, because I believe this is the first time anyone has tried building our Tcl bindings for the MSVC case (as opposed to Cygwin which Arjen has pioneered for Tcl and MinGW/MSYS(Wine) which I have pioneered for Tcl). So I believe you are pioneering your particular MSVC platform for Tcl which is good for making the build system more robust for that case and a most welcome result if you are able to achieve success. I think the most helpful suggestion I can make (other than the cmake -P test.cmake trick) is to isolate the non-blank build-system issues (if any) with your MSVC platform and Tcl by copying the whole directory tree "C:Program Files/Tcl" to "C:Program_Files/Tcl" (or else try reinstalling with that unblank prefix without interfering with the blank one). Then adjust CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH so the nonblank Tcl version is being found by CMake. Once that simpler case is working for you, then you can move back to trying the case with a blank in the Tcl system path to flush out any remaining blank-related Tcl build-system issues. 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-08-29 09:08:38
|
Hi Alan I have cured the actual link errors - I was trying to link 64 bit tcl libraries into 32 bit plplot examples - obviously it didn't work. The only real issue left is the appended .lib outside the quotes. I can't find if that is something that we do or something that CMake does. I expected to find a TARGET_LINK_LIBRARIES call with either items from DRIVERS_LINK_FLAGS or ntk_LINK_FLAGS somewhere, but I can't find it. Phil From: phil rosenberg <phi...@ya...> To: Alan W. Irwin <ir...@be...> Cc: PLplot development list <plp...@li...> Sent: Friday, 29 August 2014, 0:18 Subject: Re: [Plplot-devel] tcl build problem Hi Alan I found the same location in the file you specified between checking emails. I have been through and added the \" where appropriate to the various (rpath, compile, linker) flags. This allows me to compile, but I am getting linker errors in the examples, because the linker flags are ending up as "C:/Program Files/Tcl/lib/tcl86.lib".lib I'm not sure where the extra .lib is appearing from. If I fix this manually I then get further linker errors which seem to be name decoration static vs dynamic library issues. I will have to figure those out on my system. From: Alan W. Irwin <ir...@be...> To: Phil Rosenberg <phi...@ya...> Cc: PLplot development list <plp...@li...> Sent: Thursday, 28 August 2014, 21:29 Subject: RE: [Plplot-devel] tcl build problem On 2014-08-28 20:33+0100 Phil Rosenberg wrote: > Hi Alan > Given what you said I did a quick google for cmake paths spaces and immediately found this post http://stackoverflow.com/questions/9964775/using-cmakes-include-directories-command-with-white-spaces. Seems the issue is the same there and is a result of the find modules assuming no whitespace. I'll see if I can work out where the quotes should go and if not then I'll uninstall and reinstall tcl I guess. Hi Phil: I mostly agree with everything I read at that stackoverflow site but compile flags are a special case where the result must be a blank delimited string (as opposed to a CMake list). Looking further (in cmake/modules/tk.cmake) the culprit appears to be the command set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}") (where it just happens -I${TCL_INCLUDE_PATH} and ${TKLIB_COMPILE_FLAGS} refer to the same thing on your system, but on other systems they can be different and the repeat duplicate -I options should not be an issue on your system. When faced with CMake logic issues, it is always a good idea to make a few-line file to test out possibilities. In this case my test file (test.cmake) reads # Note the quotes which keep TCL_INCLUDE_PATH and TKLIB_COMPILE_FLAGS # from being lists. I think these represent the CMake variables # exactly on your system. set(TCL_INCLUDE_PATH "C:/Program Files/Tcl/include") set(TKLIB_COMPILE_FLAGS "-IC:/Program Files/Tcl/include") #Wrong (as currently the case in cmake/modules/tk.cmake) set(ntk_COMPILE_FLAGS "-I${TCL_INCLUDE_PATH} ${TKLIB_COMPILE_FLAGS}") message(STATUS "wrong ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}") #Right (I hope) set(ntk_COMPILE_FLAGS "\"-I${TCL_INCLUDE_PATH}\" \"${TKLIB_COMPILE_FLAGS}\"") message(STATUS "right ntk_COMPILE_FLAGS = ${ntk_COMPILE_FLAGS}") and you run it like this: irwin@raven> cmake -P test.cmake -- wrong ntk_COMPILE_FLAGS = -IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include -- right ntk_COMPILE_FLAGS = "-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include" I suggest you change cmake/modules/tk.cmake to conform to the second form, and then observe (via the VERBOSE=1 option on nmake) the resulting build command. My hope is that one string with blank-separated entities that are themselves quoted using escaped quotes (the "right" version above) will force CMake to generate compile options of either "-IC:/Program Files/Tcl/include" "-IC:/Program Files/Tcl/include" or -IC:/Program Files/Tcl/include -IC:/Program Files/Tcl/include But let me know what the VERBOSE=1 nmake option tells you about the actual build command that results from the above change. 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-08-29 16:16:47
|
On 2014-08-29 02:08-0700 phil rosenberg wrote: > Hi Alan > I have cured the actual link errors - I was trying to link 64 bit tcl libraries into 32 bit plplot examples - obviously it didn't work. > > The only real issue left is the appended .lib outside the quotes. I can't find if that is something that we do or something that CMake does. I expected to find a TARGET_LINK_LIBRARIES call with either items from DRIVERS_LINK_FLAGS or ntk_LINK_FLAGS somewhere, but I can't find it. Hi Phil: Because of your subscription concerns which I discussed with you off list, I am going to send this to you twice as a test of your subscription; once via the list and once only to you. So if you get two duplicate e-mails you know all is well with your subscription. That's excellent news that you whittled down all build system issues for your MSVC platform to just one, the appended .lib. I would like to google for that issue (in case it is a CMake bug rather than a bug in our particular build system implementation). So I need to know the exact CMake generator and MSVC version that you are using. Also, if you are not currently using the -G"NMake Makefiles" generator, I would switch to that one to see if the problem disappears. And also switch to the latest CMake 2.8.x version which is currently 2.8.12.2. The reason I suggest these two changes is that the various Windows IDE generators are notoriously buggy compared to the NMake generator, but 2.8.12.2 gives you the best chance of being bug free amongst all the CMake-2.8.x alternatives. (Note that the lastest stable CMake now is version 3.0.1, but our build system is not really ready for CMake-3.0.x which is why I have suggested trying the latest CMake in the 2.8.x.y series.) With those preliminaries out of the way, it is now time to actually answer your specific question above. :-) ntk_LINK_FLAGS is used in the loop through all drivers that occurs in drivers/CMakeLists.txt. In that file, look for if(ENABLE_DYNDRIVERS) [...] foreach(SOURCE_ROOT_NAME ${DRIVERS_LIST}) where DRIVERS_LIST includes ntk so later in the logic ${SOURCE_ROOT_NAME}_LINK_FLAGS corresponds to ntk_LINK_FLAGS. Thus, if you uncomment #message("${SOURCE_ROOT_NAME}_LINK_FLAGS = ${${SOURCE_ROOT_NAME}_LINK_FLAGS}") and #message("${SOURCE_ROOT_NAME}_TARGETS = ${${SOURCE_ROOT_NAME}_TARGETS}") those will help you to see what is going on. Also, later on in that loop logic for the non-qt case you will see the following logic: add_library(${SOURCE_ROOT_NAME} MODULE ${${SOURCE_ROOT_NAME}_SOURCE}) target_link_libraries( ${SOURCE_ROOT_NAME} plplot${LIB_TAG} ${MATH_LIB} ${${SOURCE_ROOT_NAME}_LINK_FLAGS} ${${SOURCE_ROOT_NAME}_TARGETS} ) Note, in this case ${SOURCE_ROOT_NAME}_LINK_FLAGS should be a CMake list, i.e., output in message in the form "a;b;c" where a, b, and c are the elements of the list that should get translated on the command line (revealed by the VERBOSE=1 option) to a space-separated list of linker options) However, if your message output for ${SOURCE_ROOT_NAME}_LINK_FLAGS and ${SOURCE_ROOT_NAME}_TARGETS doesn't show anything peculiar, then my bet is you are running into some kind of CMake bug for the particular CMake version and generator that you are using which motivates my suggestion above to move to the most bug-free version of CMake-2.8.x.y as well as the NMake generator (which typically is more reliable than any of the Windows IDE generators). 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-08-29 17:22:51
|
Hi Alan Got both your messages. Unfortunately that cannot be where the external libraries are linked into the examples as I am building static libraries so almost that entire file (including the section you indicated) is skipped. Just to be clear, Plplot itself is building fine, the linker error is when building the examples. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 29/08/2014 17:16 To: "PLplot development list" <plp...@li...> Subject: Re: [Plplot-devel] tcl build problem On 2014-08-29 02:08-0700 phil rosenberg wrote: > Hi Alan > I have cured the actual link errors - I was trying to link 64 bit tcl libraries into 32 bit plplot examples - obviously it didn't work. > > The only real issue left is the appended .lib outside the quotes. I can't find if that is something that we do or something that CMake does. I expected to find a TARGET_LINK_LIBRARIES call with either items from DRIVERS_LINK_FLAGS or ntk_LINK_FLAGS somewhere, but I can't find it. Hi Phil: Because of your subscription concerns which I discussed with you off list, I am going to send this to you twice as a test of your subscription; once via the list and once only to you. So if you get two duplicate e-mails you know all is well with your subscription. That's excellent news that you whittled down all build system issues for your MSVC platform to just one, the appended .lib. I would like to google for that issue (in case it is a CMake bug rather than a bug in our particular build system implementation). So I need to know the exact CMake generator and MSVC version that you are using. Also, if you are not currently using the -G"NMake Makefiles" generator, I would switch to that one to see if the problem disappears. And also switch to the latest CMake 2.8.x version which is currently 2.8.12.2. The reason I suggest these two changes is that the various Windows IDE generators are notoriously buggy compared to the NMake generator, but 2.8.12.2 gives you the best chance of being bug free amongst all the CMake-2.8.x alternatives. (Note that the lastest stable CMake now is version 3.0.1, but our build system is not really ready for CMake-3.0.x which is why I have suggested trying the latest CMake in the 2.8.x.y series.) With those preliminaries out of the way, it is now time to actually answer your specific question above. :-) ntk_LINK_FLAGS is used in the loop through all drivers that occurs in drivers/CMakeLists.txt. In that file, look for if(ENABLE_DYNDRIVERS) [...] foreach(SOURCE_ROOT_NAME ${DRIVERS_LIST}) where DRIVERS_LIST includes ntk so later in the logic ${SOURCE_ROOT_NAME}_LINK_FLAGS corresponds to ntk_LINK_FLAGS. Thus, if you uncomment #message("${SOURCE_ROOT_NAME}_LINK_FLAGS = ${${SOURCE_ROOT_NAME}_LINK_FLAGS}") and #message("${SOURCE_ROOT_NAME}_TARGETS = ${${SOURCE_ROOT_NAME}_TARGETS}") those will help you to see what is going on. Also, later on in that loop logic for the non-qt case you will see the following logic: add_library(${SOURCE_ROOT_NAME} MODULE ${${SOURCE_ROOT_NAME}_SOURCE}) target_link_libraries( ${SOURCE_ROOT_NAME} plplot${LIB_TAG} ${MATH_LIB} ${${SOURCE_ROOT_NAME}_LINK_FLAGS} ${${SOURCE_ROOT_NAME}_TARGETS} ) Note, in this case ${SOURCE_ROOT_NAME}_LINK_FLAGS should be a CMake list, i.e., output in message in the form "a;b;c" where a, b, and c are the elements of the list that should get translated on the command line (revealed by the VERBOSE=1 option) to a space-separated list of linker options) However, if your message output for ${SOURCE_ROOT_NAME}_LINK_FLAGS and ${SOURCE_ROOT_NAME}_TARGETS doesn't show anything peculiar, then my bet is you are running into some kind of CMake bug for the particular CMake version and generator that you are using which motivates my suggestion above to move to the most bug-free version of CMake-2.8.x.y as well as the NMake generator (which typically is more reliable than any of the Windows IDE generators). 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 __________________________ ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2014-08-29 19:12:09
|
On 2014-08-29 18:22+0100 Phil Rosenberg wrote: > Hi Alan > Got both your messages. Unfortunately that cannot be where the external libraries are linked into the examples as I am building static libraries so almost that entire file (including the section you indicated) is skipped. > Just to be clear, Plplot itself is building fine, the linker error is when building the examples. When the plplot library is built as a static library, the devices are no longer independent DLL's, and instead the device code is inserted into the plplot library so all device compile flags and link flags need to be accumulated for that library. Of course, that is pretty difficult to get all that implemented correctly because of the large number of device drivers with many different dependencies so note my remarks below about also testing the default shared plplot library/dynamic devices case. The relevant CMake logic for the static plplot library case is in src/CMakeLists.txt (where the plplot library build is configured). In that case look for else(ENABLE_DYNDRIVERS) list(APPEND libplplot${LIB_TAG}_LINK_LIBRARIES ${DRIVERS_LINK_FLAGS}) [...] endif(ENABLE_DYNDRIVERS) [...] #message(STATUS #"libplplot${LIB_TAG}_LINK_LIBRARIES = ${libplplot${LIB_TAG}_LINK_LIBRARIES}" #) target_link_libraries( plplot${LIB_TAG} ${libplplot${LIB_TAG}_LINK_LIBRARIES} ) You should uncomment that message command to look at the CMake list in libplplot${LIB_TAG}_LINK_LIBRARIES to see if there is anything strange there in the static libraries case. Of course, you have stated that the static plplot library is building OK, but the trouble you are having with example builds may originate in how that library is built. What you said before about the extra .lib issue was 'This allows me to compile, but I am getting linker errors in the examples, because the linker flags are ending up as "C:/Program Files/Tcl/lib/tcl86.lib".lib' To proceed further I need complete information. Therefore, please send the usual that I always request for a complete bug report: cmake version, complete cmake options used, complete output from cmake command starting from initially empty build tree, complete (VERBOSE=1) output from (n)make command, CMakeCache.txt file. The first two items you can send just as part of the main text part of your next post here, but the remaining items should be packed into a compressed tarball or zip file and attached to that same post. Here are some further possibilities to consider: Use CMake-2.8.12.2 and the NMake generator (for the reasons I gave before). Also, the static plplot library case is not nearly as well debugged for our build system as the default shared libraries/dynamic devices case. Therefore, I would also try that default case (which would be an additional valuable test of building the Tcl/Tk bindings for your platform). Of course, remember to use the -DTEST_DYNDRIVERS=OFF workaround that is normally required for this case on Windows (to avoid doing the simple test of dynamic devices that fails on Windows when the same test with essentially the same code succeeds when run from the plplot library on Windows! Go figure....) 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-08-30 13:04:19
|
Right I have now gotten to the bottom of all this The include directories must contain quotes but the link libraries must not. Presumably the difference is because we pass include directories by first prepending -I to them and passing them in as compile flags so they are handed straight to the compiler in raw form. Whereas libraries are passed as filenames to CMake and are processed before being passed to the compiler. The only ambiguity left is that I don't know what the situation should be for the RPATH variables as I don't really know what they do or how they are used. Alan can you advise? Phil ________________________________ From: phil rosenberg <phi...@ya...> To: Alan W. Irwin <ir...@be...> Sent: Saturday, 30 August 2014, 12:39 Subject: Re: [Plplot-devel] tcl build problem Hello Alan Okay so here goes, please bear with me with all this. 1) I am already using CMAKE 3.0. I presume this is from when I had wxWidgets problams and was discussing things with Brad. 2) I tried using the nmake generator. It failed. It tried to build a test program to test the compiler, which failed - cl.exe reported "could not find kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. This is obviously ridiculous as I clearly have a working c compiler. 3) I unfortunately don't have time to start fighting with the NMake generator so I am returning back to the visual studio generator. 4) The missing piece of information that led to me getting the cMAKE sequence correct was that when calling target_link_libraries and adding a library that you are building, all libraries added to that library are added as well. Note however that (at least for the VS generator) if I add libraries to a library they don't actually get added!!! Confused? Well so have I been. Basically we add all the dependancies to the plplot library. CMake remembers we have added them, but when it creates the plplot project it doesn't actually add them as additional dependancies. Then when we add plplot to the examples, it adds all the dependancies too. I'm sure you can see why I had a hard time working out what was going on and understanding your comments. 4) The output of the CMAKE command is as follows, note that I uncommented the lines to output libplplot_LINK_LIBRARIES, just before the target_link_libraries call. D:\usr\local\src\plplot-plplot\build\Visual Studio 11 64sd>cmake "D:\usr\local\s rc\plplot-plplot" -G "Visual Studio 11 Win64" -DPL_DOUBLE=ON -DBUILD_TEST=ON -DC MAKE_INSTALL_LIBDIR="D:\usr\local\lib64sd" -DCMAKE_INSTALL_PREFIX="D:\usr\local" -DCMAKE_LIBRARY_PATH="D:\usr\local\lib64sd" -DBUILD_SHARED_LIBS=OFF -DCMAKE_CON FIGURATION_TYPES="Debug" -DSTATIC_RUNTIME=ON -DwxWidgets_CONFIGURATION=mswud -DE NABLE_d=OFF -- Explicitly setting policy CMP0022 to OLD -- Explicitly setting policy CMP0023 to OLD -- CMake version = 3.0.20140224-g228d0 -- CMAKE_SYSTEM_NAME = Windows -- SH_EXECUTABLE = C:/cygwin64/bin/bash.exe -- Checking whether system has ANSI C header files -- Looking for 4 include files stdlib.h, ..., float.h -- Looking for 4 include files stdlib.h, ..., float.h - found -- Performing Test memchrExists -- Performing Test memchrExists - Success -- Performing Test freeExists -- Performing Test freeExists - Success -- Check for whether ctype.h macros work on characters with the high bit set. -- High-bit characters - work -- ANSI C header files - found -- Looking for include file unistd.h -- Looking for include file unistd.h - not found -- Looking for include file termios.h -- Looking for include file termios.h - not found -- Looking for include file stdint.h -- Looking for include file stdint.h - found -- Looking for crt_externs.h -- Looking for crt_externs.h - not found -- Performing Test HAVE_SYS_WAIT_H -- Performing Test HAVE_SYS_WAIT_H - Failed -- Looking for DIR in sys/types.h;dirent.h -- Looking for DIR in sys/types.h;dirent.h - not found. -- Looking for DIR in sys/types.h;sys/ndir.h -- Looking for DIR in sys/types.h;sys/ndir.h - not found. -- Looking for DIR in sys/types.h;sys/dir.h -- Looking for DIR in sys/types.h;sys/dir.h - not found. -- Looking for DIR in sys/types.h;ndir.h -- Looking for DIR in sys/types.h;ndir.h - not found. -- Check for signal return type in <signal.h> -- Check for signal handler return type type void - found -- Looking for popen -- Looking for popen - not found -- Looking for usleep -- Looking for usleep - not found -- Looking for nanosleep -- Looking for nanosleep - not found -- Looking for mkstemp -- Looking for mkstemp - not found -- Looking for mkdtemp -- Looking for mkdtemp - not found -- Looking for mkfifo -- Looking for mkfifo - not found -- Looking for unlink -- Looking for unlink - found -- Looking for _NSGetArgc -- Looking for _NSGetArgc - not found -- Looking for isfinite -- Looking for isfinite - not found -- Looking for finite -- Looking for finite - not found -- Looking for finite -- Looking for finite - not found -- Looking for _finite -- Looking for _finite - not found -- Looking for _finite -- Looking for _finite - found -- Looking for isnan -- Looking for isnan - not found -- Looking for isnan -- Looking for isnan - not found -- Looking for _isnan -- Looking for _isnan - not found -- Looking for _isnan -- Looking for _isnan - found -- Looking for isinf -- Looking for isinf - not found -- Looking for isinf -- Looking for isinf - not found -- Looking for _isinf -- Looking for _isinf - not found -- Looking for _isinf -- Looking for _isinf - not found -- Looking for snprintf -- Looking for snprintf - not found -- Looking for _snprintf -- Looking for _snprintf - found -- SWIG was not found. Please specify Swig executable location -- Found Perl: C:/Program Files (x86)/MiKTeX 2.9/miktex/bin/perl.exe (found vers ion "5.16.3") -- WARNING: Perl module XML::Parser not found -- WARNING: Perl module XML::DOM not found -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) -- Looking for pkg-config - not found -- WARNING: Makefile+pkg-config version of examples build in the install tree wi ll not work. -- X11_FOUND = -- X11_INCLUDE_DIR = -- X11_COMPILE_FLAGS = -- X11_LIBRARIES = -- The C compiler identification is MSVC 17.0.61030.0 -- Check for working C compiler using: Visual Studio 11 2012 Win64 -- Check for working C compiler using: Visual Studio 11 2012 Win64 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMAKE_GENERATOR = Visual Studio 11 2012 Win64 -- The CXX compiler identification is MSVC 17.0.61030.0 -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64sd/language_tests/CXX -- Check for using namespace support -- Check for using namespace - found -- Looking for C++ include cmath -- Looking for C++ include cmath - found -- Check for using stdint.h with CXX compiler -- Check for using stdint.h with CXX compiler - ok -- The C compiler identification is MSVC 17.0.61030.0 -- Check for working C compiler using: Visual Studio 11 2012 Win64 -- Check for working C compiler using: Visual Studio 11 2012 Win64 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMAKE_GENERATOR = Visual Studio 11 2012 Win64 -- The Fortran compiler identification is unknown CMake Error at CMakeLists.txt:33 (enable_language): No CMAKE_Fortran_COMPILER could be found. -- Configuring incomplete, errors occurred! See also "D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64sd/language_te sts/Fortran/CMakeFiles/CMakeOutput.log". See also "D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64sd/language_te sts/Fortran/CMakeFiles/CMakeError.log". -- WARNING: no working Fortran compiler so disabling Fortran bindings and exampl es. -- WARNING: Java requires shared libraries. Disabling java bindings -- WARNING: Python requires shared libraries. Disabling Python bindings -- WARNING: swig not found. Disabling Octave bindings -- Start determining consistent system data for Tcl and friends -- Found Tclsh: C:/Program Files/Tcl/bin/tclsh.exe (found version "8.6") -- Found TCL: C:/Program Files/Tcl/lib/tcl86.lib -- Found TCLTK: C:/Program Files/Tcl/lib/tcl86.lib -- Found TK: C:/Program Files/Tcl/lib/tk86.lib -- Looking for Tcl - found -- TCL_INCLUDE_PATH = C:/Program Files/Tcl/include -- TCL_LIBRARY = C:/Program Files/Tcl/lib/tcl86.lib -- TCL_STUB_LIBRARY = C:/Program Files/Tcl/lib/tclstub86.lib -- TCL_LIBRARY_PATH = C:/Program Files/Tcl/lib -- Looking for tclsh - found -- TCL_TCLSH = C:/Program Files/Tcl/bin/tclsh.exe -- Looking for Tcl version with tclsh - found -- PLPLOT_TCL_VERSION = 8.6.1 -- Looking for itcl.h -- Looking for itcl.h - not found -- WARNING: Disabling Itcl interface code -- Looking for Tk - found -- TK_INCLUDE_PATH = C:/Program Files/Tcl/include -- TK_LIBRARY = C:/Program Files/Tcl/lib/tk86.lib -- TK_STUB_LIBRARY = C:/Program Files/Tcl/lib/tkstub86.lib -- TK_LIBRARY_PATH = C:/Program Files/Tcl/lib -- Looking for wish - found -- TK_WISH = C:/Program Files/Tcl/bin/wish.exe -- Looking for Tk version with wish - found -- Tcl and Tk versions found by both tclsh and wish are identical -- Looking for itk.h -- Looking for itk.h - not found -- WARNING: Disabling Itk interface code -- TCL_RPATH = C:/Program Files/Tcl/lib -- TCL_TK_RPATH = C:/Program Files/Tcl/lib -- TCL_TK_ITCL_ITK_RPATH = C:/Program Files/Tcl/lib -- Finished determining consistent system data for Tcl and friends -- The C compiler identification is MSVC 17.0.61030.0 -- Check for working C compiler using: Visual Studio 11 2012 Win64 -- Check for working C compiler using: Visual Studio 11 2012 Win64 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMAKE_GENERATOR = Visual Studio 11 2012 Win64 -- Check for working Ada builder: C:/cygwin64/bin/gnatmake.exe CMake Error: Could not find cmake module file: CMakeAdaInformation.cmake CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working Ada builder: C:C/Mcygawkien 6E4r/rboirn /agtn aDt:m/aukser. lelxoec a-l-/ sbrrco/kpelnp ot-plplot/cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake:48 (ME SSAGE): The Ada builder "C:/cygwin64/bin/gnatmake.exe" is not able to compile, bind, and link a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:33 (enable_language) -- Configuring incomplete, errors occurred! See also "D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64sd/language_te sts/Ada/CMakeFiles/CMakeOutput.log". See also "D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64sd/language_te sts/Ada/CMakeFiles/CMakeError.log". -- WARNING: no working Ada compiler so disabling Ada bindings and examples. -- WARNING: Lua requires shared libraries. Disabling Lua bindings -- FindShapelib: Found shapelib header directory, D:/usr/local/include, and libr ary, D:/usr/local/lib64sd/shapelib.lib. -- Found Freetype: D:/usr/local/lib64sd/freetype.lib -- FREETYPE_CFLAGS = -ID:/usr/local/include/freetype2 -ID:/usr/local/include -- FREETYPE_LIBRARIES = D:/usr/local/lib64sd/freetype.lib -- Check for NaN awareness in C compiler -- Check for NaN awareness in C compiler - found -- WARNING: qhull library not found. Setting PL_HAVE_QHULL to OFF. -- WARNING: pango not found because pkg-config not available. -- WARNING: Shared libraries not built. Setting ENABLE_DYNDRIVERS OFF. -- WARNING: pkg-config not found. Setting cairo drivers to OFF. -- WARNING: X11 not found. Therefore turning off tk and tkwin devices that depe nd on it -- TKLIB_COMPILE_FLAGS -I"C:/Program Files/Tcl/include" -- ntk_COMPILE_FLAGS -I"C:/Program Files/Tcl/include" -I"C:/Program Files/Tcl/in clude" -- ntk_LINK_FLAGS "C:/Program Files/Tcl/lib/tcl86.lib";"C:/Program Files/Tcl/lib /tk86.lib" -- ntk_RPATH "C:/Program Files/Tcl/lib" -- WARNING: pkg-config not found. Setting PLD_psttf to OFF. -- Found unsuitable Qt version "" from NOTFOUND -- WARNING: Suitable Qt4 development environment not found so disabling Qt bindi ngs. -- WARNING: ENABLE_qt is OFF so setting all qt devices to OFF. -- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4 to OFF. CMake Warning at cmake/modules/qt.cmake:349 (find_package): By not providing "FindSmoke.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Smoke", but CMake did not find one. Could not find a package configuration file provided by "Smoke" with any of the following names: SmokeConfig.cmake smoke-config.cmake Add the installation prefix of "Smoke" to CMAKE_PREFIX_PATH or set "Smoke_DIR" to a directory containing one of the above files. If "Smoke" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): cmake/modules/drivers.cmake:95 (include) cmake/modules/plplot.cmake:551 (include) CMakeLists.txt:111 (include) -- WARNING: smoke not found so setting ENABLE_smoke to OFF. -- Looking for gdi32 header and library -- Looking for gdi32 header and library - not found -- WARNING: Setting PLD_wingcc to OFF. -- wxWidgets found -- wxwidgets_COMPILE_FLAGS = -ID:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x6 4_lib/mswud -ID:/SourceCode/Libraries/wxWidgets-3.0.0/include -DUNICODE -D_UNICO DE -- wxwidgets_LINK_FLAGS = D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib /wxbase30ud.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wxmsw30ud _core.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wxpngd.lib;D:/S ourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wxtiffd.lib;D:/SourceCode/Lib raries/wxWidgets-3.0.0/lib/vc_x64_lib/wxjpegd.lib;D:/SourceCode/Libraries/wxWidg ets-3.0.0/lib/vc_x64_lib/wxzlibd.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib /vc_x64_lib/wxregexud.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib /wxexpatd.lib;winmm;comctl32;rpcrt4;wsock32 -- Could NOT find AGG (missing: AGG_LIBRARIES AGG_INCLUDE_DIR) -- WARNING: AGG not found. Setting HAVE_AGG to OFF. -- WARNING: wxwidgets driver and bindings components depending on AGG library ha ve been dropped. -- Looking for haru pdf header and library -- Looking for haru pdf header and library - not found -- WARNING: Setting PLD_pdf to OFF. -- WARNING:Static build with ENABLE_ocaml_static false. Therefore, disabling oc aml bindings -- WARNING:ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support -- WARNING: validate target will not be available to check for syntax issues in the PLplot DocBook documentation because onsgmls (or env) was not found. -- WARNING: execute_process failed to obtain C++ library needed for pkg-config -- CMAKE_CXX_COMPILER = C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/b in/x86_amd64/cl.exe -- CXX_rc = 2 -- CXX_string = Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x64 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line warning D9002 : ignoring unknown option '--verbose' cl : Command line warning D9002 : ignoring unknown option '--version' cl : Command line error D8003 : missing source filename -- WARNING: failed to find libstdc++ so pkg-config link flags will be incomplete -- libplplot_LINK_LIBRARIES = "C:/Program Files/Tcl/lib/tcl86.lib";"C:/Program F iles/Tcl/lib/tk86.lib";D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wx base30ud.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wxmsw30ud_co re.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wxpngd.lib;D:/Sour ceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wxtiffd.lib;D:/SourceCode/Librar ies/wxWidgets-3.0.0/lib/vc_x64_lib/wxjpegd.lib;D:/SourceCode/Libraries/wxWidgets -3.0.0/lib/vc_x64_lib/wxzlibd.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc _x64_lib/wxregexud.lib;D:/SourceCode/Libraries/wxWidgets-3.0.0/lib/vc_x64_lib/wx expatd.lib;winmm;comctl32;rpcrt4;wsock32;D:/usr/local/lib64sd/freetype.lib;D:/us r/local/lib64sd/shapelib.lib;D:/usr/local/lib64sd/freetype.lib;csirocsa;qsastime -- WARNING: Perl modules XML::Parser and/or XML::DOM not available so cannot check that swig_documentation.i is up to date. -- ENABLE_itcl: OFF -- Itcl libraries: plplot;C:/Program Files/Tcl/lib/tcl86.lib CMake Warning (dev) at bindings/tcl/CMakeLists.txt:490 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "plplottcltk". Use the target name directly with add_custom_command, or use the generator expression $<TARGET_FILE>, as appropriate. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) in src/CMakeLists.txt: Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "plplot". Use the target name directly with add_custom_command, or use the generator expression $<TARGET_FILE>, as appropriate. This warning is for project developers. Use -Wno-dev to suppress it. -- WARNING: pkg-config not found so plplotcanvas_demo, plplotcanvas_animation, extXdrawable_demo, and ext-cairo-test not built. CMake Warning (dev) in bindings/tcl/CMakeLists.txt: Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "pltcl". Use the target name directly with add_custom_command, or use the generator expression $<TARGET_FILE>, as appropriate. This warning is for project developers. Use -Wno-dev to suppress it. -- WARNING: The test_pltcl_standard_examples target can be run independently on the Windows platform, but it generates an unhandled exception at the end so it is temporarily excluded from being a dependency of other more general interactive test targets CMake Warning (dev) in bindings/tcl/CMakeLists.txt: Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "pltcl". Use the target name directly with add_custom_command, or use the generator expression $<TARGET_FILE>, as appropriate. This warning is for project developers. Use -Wno-dev to suppress it. Summary of CMake build system results for PLplot Install location variables which can be set by the user: CMAKE_INSTALL_PREFIX: D:/usr/local CMAKE_INSTALL_EXEC_PREFIX D:/usr/local CMAKE_INSTALL_BINDIR D:/usr/local/bin CMAKE_INSTALL_DATADIR D:/usr/local/share CMAKE_INSTALL_LIBDIR D:/usr/local/lib64sd CMAKE_INSTALL_INCLUDEDIR D:/usr/local/include CMAKE_INSTALL_INFODIR D:/usr/local/share/info CMAKE_INSTALL_MANDIR D:/usr/local/share/man Derived install location variables: DATA_DIR D:/usr/local/share/plplot5.10.0 LIB_DIR D:/usr/local/lib64sd INCLUDE_DIR D:/usr/local/include/plplot BIN_DIR D:/usr/local/bin TCL_DIR D:/usr/local/share/plplot5.10.0/tcl ADA_INCLUDE_DIR D:/usr/local/share/ada/adainclude/plplotada ADA_LIB_DIR D:/usr/local/lib64sd/ada/adalib/plplotada PYTHON_INSTDIR DRV_DIR D:/usr/local/lib64sd/plplot5.10.0/drivers DOC_DIR D:/usr/local/share/doc/plplot MAN_DIR D:/usr/local/share/man INFO_DIR D:/usr/local/share/info Other important CMake variables: CMAKE_SYSTEM_NAME: Windows UNIX: WIN32: 1 APPLE: MSVC: 1 (MSVC_VERSION: 1700) MINGW: MSYS: CYGWIN: BORLAND: WATCOM: SWIG_FOUND: FALSE PERL_FOUND: TRUE X11_FOUND: CMAKE_BUILD_TYPE: CMAKE_C_COMPILER CMAKE_C_FLAGS: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/x86_amd64/cl.exe /DUNICODE /D_UNICODE /DWIN32 /D_WIND OWS /W3 CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/x86_amd64/cl.exe /DUNICODE /D_UNICODE /DWIN32 /D_WIND OWS /W3 /GR /EHsc LIB_TAG: ENABLE_DYNDRIVERS: OFF DRIVERS_LIST: mem;ntk;null;ps;svg;wxwidgets;xfig DEVICES_LIST: mem;ntk;null;ps;svg;wxwidgets;xfig Library options: BUILD_SHARED_LIBS: OFF PL_DOUBLE: ON Optional libraries: PL_HAVE_QHULL: OFF WITH_CSA: ON PL_HAVE_FREETYPE: ON PL_HAVE_PTHREAD: HAVE_AGG: OFF HAVE_SHAPELIB: ON Language Bindings: ENABLE_ada: OFF ENABLE_cxx: ON ENABLE_d: OFF ENABLE_f95: OFF ENABLE_java: OFF ENABLE_lua: OFF ENABLE_ocaml: OFF ENABLE_octave: OFF ENABLE_pdl: OFF ENABLE_python: OFF ENABLE_qt: OFF ENABLE_pyqt4: OFF ENABLE_tcl: ON ENABLE_itcl: OFF ENABLE_tk: ON ENABLE_itk: OFF ENABLE_wxwidgets: ON -- Configuring done CMake Warning (dev) at examples/CMakeLists.txt:955 (add_dependencies): Policy CMP0046 is not set: Error on non-existent dependency in add_dependencies. Run "cmake --help-policy CMP0046" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The dependency target "ntk" of target "test_pltcl_standard_examples" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) in bindings/wxwidgets/CMakeLists.txt: Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_<Config> properties. Run "cmake --help-policy CMP0043" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- Generating done -- Build files have been written to: D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64sd 5)You will notice that at this point the extra .lib has not been appended. Which makes me conclude this is a CMake bug. presumably somewhere it checks if the libraries end in .lib and if not it appends this suffix, but fails to account for quoted paths. 6) I have also included the cake.cache zipped as an attachment. 7)Frustratingly these build problems just keep on coming up in Windows - Windows is rather more ad-hoc with building from source than Linux. Often libraries are not where one might expect and people regularly use static libraries and static runtimes. Then there is the Unicode issue. On Linux the runtime is included with the distro so in general everyone uses dynamic runtime and as Linux has a package manager things are almost always where you expect and it is generally relatively easy to add a dependant library if it is missing and deal with dll hell. I'm not sure what the suitable answer is - I'm not sure if there is any way to become less dependant upon Cmake or even if that would be a good thing. It's just a shame CMake isn't at a stage yet where it "just works" on Windows. Phil From: Alan W. Irwin <ir...@be...> To: Phil Rosenberg <phi...@ya...> Cc: PLplot development list <plp...@li...> Sent: Friday, 29 August 2014, 20:12 Subject: RE: [Plplot-devel] tcl build problem On 2014-08-29 18:22+0100 Phil Rosenberg wrote: > Hi Alan > Got both your messages. Unfortunately that cannot be where the external libraries are linked into the examples as I am building static libraries so almost that entire file (including the section you indicated) is skipped. > Just to be clear, Plplot itself is building fine, the linker error is when building the examples. When the plplot library is built as a static library, the devices are no longer independent DLL's, and instead the device code is inserted into the plplot library so all device compile flags and link flags need to be accumulated for that library. Of course, that is pretty difficult to get all that implemented correctly because of the large number of device drivers with many different dependencies so note my remarks below about also testing the default shared plplot library/dynamic devices case. The relevant CMake logic for the static plplot library case is in src/CMakeLists.txt (where the plplot library build is configured). In that case look for else(ENABLE_DYNDRIVERS) list(APPEND libplplot${LIB_TAG}_LINK_LIBRARIES ${DRIVERS_LINK_FLAGS}) [...] endif(ENABLE_DYNDRIVERS) [...] #message(STATUS #"libplplot${LIB_TAG}_LINK_LIBRARIES = ${libplplot${LIB_TAG}_LINK_LIBRARIES}" #) target_link_libraries( plplot${LIB_TAG} ${libplplot${LIB_TAG}_LINK_LIBRARIES} ) You should uncomment that message command to look at the CMake list in libplplot${LIB_TAG}_LINK_LIBRARIES to see if there is anything strange there in the static libraries case. Of course, you have stated that the static plplot library is building OK, but the trouble you are having with example builds may originate in how that library is built. What you said before about the extra .lib issue was 'This allows me to compile, but I am getting linker errors in the examples, because the linker flags are ending up as "C:/Program Files/Tcl/lib/tcl86.lib".lib' To proceed further I need complete information. Therefore, please send the usual that I always request for a complete bug report: cmake version, complete cmake options used, complete output from cmake command starting from initially empty build tree, complete (VERBOSE=1) output from (n)make command, CMakeCache.txt file. The first two items you can send just as part of the main text part of your next post here, but the remaining items should be packed into a compressed tarball or zip file and attached to that same post. Here are some further possibilities to consider: Use CMake-2.8.12.2 and the NMake generator (for the reasons I gave before). Also, the static plplot library case is not nearly as well debugged for our build system as the default shared libraries/dynamic devices case. Therefore, I would also try that default case (which would be an additional valuable test of building the Tcl/Tk bindings for your platform). Of course, remember to use the -DTEST_DYNDRIVERS=OFF workaround that is normally required for this case on Windows (to avoid doing the simple test of dynamic devices that fails on Windows when the same test with essentially the same code succeeds when run from the plplot library on Windows! Go figure....) 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-08-30 19:08:08
|
Hi Phil: I have also CC'd Arjen as a reminder to him to look for comments below that mention his name. :-) On 2014-08-30 06:04-0700 phil rosenberg wrote: > Right I have now gotten to the bottom of all this > > > The include directories must contain quotes but the link libraries must not. > > Presumably the difference is because we pass include directories by first prepending -I to them and passing them in as compile flags so they are handed straight to the compiler in raw form. Whereas libraries are passed as filenames to CMake and are processed before being passed to the compiler. Exactly. > The only ambiguity left is that I don't know what the situation should be for the RPATH variables as I don't really know what they do or how they are used. Alan can you advise? See http://stackoverflow.com/questions/107888/is-there-a-windows-msvc-equivalent-to-the-rpath-linker-flag for some background. My understanding is CMake just ignores RPATH settings on all Windows platforms. So you don't have to be concerned with RPATH at all. However, just in case your changes dealing with blanks have had a side-effect on RPATH that might affect other platforms, don't worry about that. If my test of your push (which I presume you will be making soon) on Linux shows you have introduced some RPATH issues on that platform, I will deal with those. It appears below, you now have gotten everything to work (subject possibly to a transitive linking issue for CMake-3 that you have worked around by hand) for the -G"Visual Studio 11 Win64" -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON case. IMPORTANT. So please go ahead and commit and push your build-system changes so I can test them here. And kudos to you for obviously learning a lot about the CMake language while pioneering the above case with Tcl/Tk installed in a prefix area that contains blanks in the name. The CMake knowledge you have developed during this effort will help you a lot down the road not only with PLplot but likely other free software projects as well. After you make that push, please go ahead and also pioneer your platform (this time with CMake-2.8.12.2, see below) without the -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON cmake options. That is the (default) case that most Windows users will be using so it would be valuable to make sure it works for your Tcl/Tk case. Further response below to some of the points you made in the forwarded section of your e-mail. > Okay so here goes, please bear with me with all this. > 1) I am already using CMAKE 3.0. I presume this is from when I had wxWidgets problams and was discussing things with Brad. I would still recommend you go back to using CMake-2.8.12.2. The problem is that CMake-3.0 is complaining about that part of our build-system that enforces transitive linking for the Windows case. And the further remarks you make about that below indicate that CMake-3-only issue may be affecting you. If you do need something from CMake-3.0 such as a more modern wxwidgets find module it is easy to try that (by copying the relevant file to cmake/modules in the PLplot source tree). And if that latest version of the find module works for you with CMake-2.8.12.2 then commit and push it to our repo so all our users still using CMake-2.8.x will benefit. > 2) I tried using the nmake generator. It failed. It tried to build a test program to test the compiler, which failed - cl.exe reported "could not find kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. This is obviously ridiculous as I clearly have a working c compiler. Can't help you there, but I bet Arjen can since he routinely uses the nmake generator without such issues. > 3) I unfortunately don't have time to start fighting with the NMake generator so I am returning back to the visual studio generator. Fair enough. I should tone down the negative things I said about the visual studio generators since you obviously got one of them to work. But I will say this: there are lots of such visual studio generators and at least one new one each year so CMake development resources to flush out the bugs are spread thin. In comparison nmake has been around forever so that generator is completely mature. Also, in your case the VS generator worked, but that may be because it is relatively mature, and when you update your VS version you will also have to update to a newer VS generator to be consistent with it. So in that case you might run into issues for a while until the genrator matures. Therefore, in my view it is always worthwhile to have the nmake generator available so I hope Arjen responds above to get you squared away with nmake to use as a reliable fallback when needed. > 4) The missing piece of information that led to me getting the cMAKE sequence correct was that when calling target_link_libraries and adding a library that you are building, all libraries added to that library are added as well. Note however that (at least for the VS generator) if I add libraries to a library they don't actually get added!!! Confused? Well so have I been. Basically we add all the dependancies to the plplot library. CMake remembers we have added them, I follow your summary thus far. However, you have to clearly distinguish what we tell CMake to do via our CMake build system logic compared with the actual build result that is generated by CMake (and which you access using the VERBOSE=1 option in the nmake case, but I don't know what is required in the VS case). For example, it is often the case that an app links to a library which links to other libraries the app is completely unaware of. (For example, our C examples link to the plplot core library but are completely unaware that that library has other library dependencies since the app uses nothing directly from those other libraries.) For this case in CMake you only express direct library dependencies in the target_link_libraries statement and ignore the indirectly linked ones. Then CMake (including the particular generator logic you are using) is supposed to translate that information into something that is correct for the platform, i.e., some platforms like Linux are completely happy with mentioning only directly linked libraries (so-called non-transitive linking) to the linker while others demand all directly and indirectly linked libraries are mentioned, i.e., so-called transitive linking. Another complication is that CMake does have issues with how non-transitive linking works on Windows so we force transitive linking in that case, and that works very well for CMake-2.8.x. (See the NON_TRANSITIVE option which is set to OFF for Windows in cmake/modules/plplot.cmake, and which is used, e.g., in src/CMakeLists.txt to force transitive linking for Windows). However, it is exactly this transitive logic in src/CMakeLists.txt and elsewhere that CMake-3 is issuing warnings about. So for CMake-3 there may be an issue such that non-transitive linking is (incorrectly) being used for Windows (see below). > but when it creates the plplot project it doesn't actually add them as additional dependancies. The VS generator should know the VS platform requirements about whether linking should be non-transitive or transitive. So if you have to enforce transitive linking by hand (by entering all those dependencies by hand), then I believe that is due to a CMake-3 inconsistency with our build-system logic (see comment above) or else possibly a VS generator bug. Of course, eventually I should be able to adjust our build system logic for the new CMake methods that are available for specifying non-transitive and transitive linking in CMake-3.0. But for now, I suggest you avoid CMake-3.0 and stick with CMake-2.8.12.2. > 4) The output of the CMAKE command is as follows, note that I uncommented the lines to output libplplot_LINK_LIBRARIES, just before the target_link_libraries call. For equivalent cases in the future, it would be much more convenient for me if you included such information in a compressed attachment (which does not subject it to mail wraparound problems). However, I did look at it this time, and the libplplot_LINK_LIBRARIES result looks OK to me. I also like > -- Start determining consistent system data for Tcl and friends [...] > -- Finished determining consistent system data for Tcl and > friends with harmless warnings in there about missing itcl and itk on your system. I also judge the other warnings you encountered to be harmless except for the CMake-3 warnings about 2.8.x code that enforces transitive linking in the Windows case and which is apparently causing some problems for you. > 7)Frustratingly these build problems just keep on coming up in Windows - Windows is rather more ad-hoc with building from source than Linux. Often libraries are not where one might expect and people regularly use static libraries and static runtimes. Then there is the Unicode issue. On Linux the runtime is included with the distro so in general everyone uses dynamic runtime and as Linux has a package manager things are almost always where you expect and it is generally relatively easy to add a dependant library if it is missing and deal with dll hell. I'm not sure what the suitable answer is - I'm not sure if there is any way to become less dependant upon Cmake or even if that would be a good thing. It's just a shame CMake isn't at a stage yet where it "just works" on Windows. I agree that free software binary distribution of individual packages of Windows is currently in a mess with a "wild-west" philosophy where there is no consistency between individual binary packages about where everything is installed, not consistent ABI, etc. (In fact, this is the fundamental reason we have never bothered with binary distribution of PLplot on Windows.) So given this situation, CMake Windows users for now have to be aware of all the tools at their disposal (such as the CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH environment variables) to provide help to CMake to find all required external libraries in various odd install locations and just cross their fingers on potential ABI inconsistency issues (unless they build everything themself with something like cmake/epa_build). Another Windows issue that CMake has faced pretty well (using, e.g., a very large and increasing number of VS generators) is there are a very large set of Windows platforms with different build rules between them. In contrast, it is obviously much easier for CMake to operate on Unix platforms where the "Unix Makefiles" generator is used in the vast majority of cases. In the long term, the solution is for a volunteer or group of such volunteers to create a free software distribution for Windows that enforces a self-consistent set of packaging rules for each free software package that is included in that particular distro. Cygwin is already one such effort (in this case backed by RedHat rather than volunteers), and MinGW-w64/MSYS2 is another such distribution that has been put together quite recently by volunteers and is rapidly gaining mindshare. So if this and similar volunteer efforts continue to expand, the known current issues with binary distribution of individual packages on Windows should eventually no longer be of concern. 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-08-31 07:37:16
|
Hi Alan thanks for all that, I'll sort out the commit asap - you will presumably see the commit alert. >However, you have to clearly distinguish what we tell CMake to do via our CMake build system logic compared with the actual build result that is generated by CMake (and which you access using the VERBOSE=1 option in the nmake case, but I don't know what is required in the VS case). For example, it is often the case that an app links to a library which links to other libraries the app is completely unaware of. (For example, our C examples link to the plplot core library but are completely unaware that that library has other library dependencies since the app uses nothing directly from those other libraries.) For this case in CMake you only express direct library dependencies in the target_link_libraries statement and ignore the indirectly linked ones. Then CMake (including the particular generator logic you are using) is supposed to translate that information into something that is correct for the platform, i.e., some platforms like Linux are completely happy with mentioning only directly linked libraries (so-called non-transitive linking) to the linker while others demand all directly and indirectly linked libraries are mentioned, i.e., so-called transitive linking. So on Windows either is acceptable - at least for static libs, dlls are a bit different. I can either link a library into a depending library then link this into my exe, or I can not link the libraries together and can link them all into the exe. One might prefer the former if multiple versions of the same library are required in one exe (e.g. imagine plplot only supported wxWidgets 2.8, but my exe used 3.0). What confused me is that CMAKE does neither of these - it appears that we tell it to link dependancies into plplot, but it doesn't, then when we tell it to link plplot into the examples it links plplot and the dependancies. This situation works fine and there is nothing to be done by hand - it just rather confused me as it isn't behaviour that corresponds to anything that can be done natively. Regarding Windows issues - yes I basically agree. I have Cygwin now and it is very useful. I now put all my open source code and libs in a Linux style tree (separate to Cygwin) with a src, bin, lib, etc structure. The reason for the separation is that libraries built with VC++ use a different runtime to those built with gcc, so although mixing the two can be done, it is easier to keep them separate. Of course by setting up a tree like this with libs all together puts the requirement upon me to manually manage dll hell - which is why I almost solely use static libs. I don't know the details of how it "should be done" on Windows. Probably some combination of registering libraries with the side-by-side service and using the MS installer which I think tracks dlls somehow. I doubt many open source libraries do any of these things as most are more Linux-centric. Thanks again for all your help Alan - sorry if my last email sounded a bit grumpy. Phil |
From: Arjen M. <Arj...@de...> - 2014-08-31 13:31:01
|
Hi Phil, Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, August 30, 2014 9:08 PM > > > 2) I tried using the nmake generator. It failed. It tried to build a > test program to test the compiler, which failed - cl.exe reported "could not find > kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. > This is obviously ridiculous as I clearly have a working c compiler. > > Can't help you there, but I bet Arjen can since he routinely uses the nmake generator > without such issues. > A missing kernel32.lib is very strange: it is one of the system libraries and it is used in just about any program. What happens if you compile a simpel C program manually: cl dummy.c? > > 3) I unfortunately don't have time to start fighting with the NMake > generator so I am returning back to the visual studio generator. > > Fair enough. I should tone down the negative things I said about the visual studio > generators since you obviously got one of them to work. > > But I will say this: there are lots of such visual studio generators and at least one new > one each year so CMake development resources to flush out the bugs are spread > thin. In comparison nmake has been around forever so that generator is completely > mature. Also, in your case the VS generator worked, but that may be because it is > relatively mature, and when you update your VS version you will also have to update > to a newer VS generator to be consistent with it. So in that case you might run into > issues for a while until the genrator matures. > Therefore, in my view it is always worthwhile to have the nmake generator available > so I hope Arjen responds above to get you squared away with nmake to use as a > reliable fallback when needed. > I find the variety of generators confusing myself. Especially since the version numbers/names of the various VS's are confusing too. > > In the long term, the solution is for a volunteer or group of such volunteers to create a > free software distribution for Windows that enforces a self-consistent set of > packaging rules for each free software package that is included in that particular > distro. Cygwin is already one such effort (in this case backed by RedHat rather than > volunteers), and MinGW-w64/MSYS2 is another such distribution that has been put > together quite recently by volunteers and is rapidly gaining mindshare. So if this and > similar volunteer efforts continue to expand, the known current issues with binary > distribution of individual packages on Windows should eventually no longer be of > concern. > That is definitely a worthwhile goal - I know some people are awed by the complexity of building third-party software and therefore decide against using it. This is more important on Windows than on Linux. The "wild west" situation Alan describes is one of the culprits. 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: Arjen M. <Arj...@de...> - 2014-09-01 07:38:24
|
Hi Phil, I have given this matter some more thought, as the problem did seem familiar. If I remember correcrly, I have seen it as a consequence of a mixup of nmake with gcc or something similar. I will try and reproduce it. Regards, Arjen From: Arjen Markus [mailto:Arj...@de...] Sent: Sunday, August 31, 2014 3:30 PM To: Alan W. Irwin; phil rosenberg Cc: PLplot development list Subject: Re: [Plplot-devel] tcl build problem Hi Phil, Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, August 30, 2014 9:08 PM > > > 2) I tried using the nmake generator. It failed. It tried to build a > test program to test the compiler, which failed - cl.exe reported "could not find > kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. > This is obviously ridiculous as I clearly have a working c compiler. > > Can't help you there, but I bet Arjen can since he routinely uses the nmake generator > without such issues. > A missing kernel32.lib is very strange: it is one of the system libraries and it is used in just about any program. What happens if you compile a simpel C program manually: cl dummy.c? > > 3) I unfortunately don't have time to start fighting with the NMake > generator so I am returning back to the visual studio generator. > > Fair enough. I should tone down the negative things I said about the visual studio > generators since you obviously got one of them to work. > > But I will say this: there are lots of such visual studio generators and at least one new > one each year so CMake development resources to flush out the bugs are spread > thin. In comparison nmake has been around forever so that generator is completely > mature. Also, in your case the VS generator worked, but that may be because it is > relatively mature, and when you update your VS version you will also have to update > to a newer VS generator to be consistent with it. So in that case you might run into > issues for a while until the genrator matures. > Therefore, in my view it is always worthwhile to have the nmake generator available > so I hope Arjen responds above to get you squared away with nmake to use as a > reliable fallback when needed. > I find the variety of generators confusing myself. Especially since the version numbers/names of the various VS's are confusing too. > > In the long term, the solution is for a volunteer or group of such volunteers to create a > free software distribution for Windows that enforces a self-consistent set of > packaging rules for each free software package that is included in that particular > distro. Cygwin is already one such effort (in this case backed by RedHat rather than > volunteers), and MinGW-w64/MSYS2 is another such distribution that has been put > together quite recently by volunteers and is rapidly gaining mindshare. So if this and > similar volunteer efforts continue to expand, the known current issues with binary > distribution of individual packages on Windows should eventually no longer be of > concern. > That is definitely a worthwhile goal - I know some people are awed by the complexity of building third-party software and therefore decide against using it. This is more important on Windows than on Linux. The "wild west" situation Alan describes is one of the culprits. 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. 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: Alan W. I. <ir...@be...> - 2014-08-31 16:55:12
|
On 2014-08-31 00:37-0700 phil rosenberg wrote: > So on Windows either is acceptable - at least for static libs, dlls are a bit different. I can either link a library into a depending library then link this into my exe, or I can not link the libraries together and can link them all into the exe. Actually, I completely screwed up my explanation of transitive versus non-transitive linking. That consideration is only appropriate for the -DBUILD_SHARED_LIBS=ON case and is ignored in the -DBUILD_SHARED_LIBS=OFF case you were testing. Your remarks about static linking for Windows agree with what I think goes on for that case on Linux as well. My understanding is a static library on any platform is essentially just a collection of object code ready to be inserted into another library or else an executable _at link time_ (as opposed to being loaded at run time which is what happens with shared libraries). So if you link plplot with a static library, the relevant parts of that static library (those that satisfy some/all of plplot's of unresolved symbols) get inserted into the plplot library. So far so good, but if you forget to do that (which I think would generally be a poor choice), then the executable inherits those undefined symbols and you have one last chance to insert the static library's code into that executable. Note, that for the PLplot build system we have adopted the choice where target_link_libraries mentions _just_ the libraries that are needed because they satisfy unresolved symbols that are directly required by the particular library or executable being linked). So if a library or executable has a direct requirement we mention it but otherwise not. This should be perfect from the point of view of static libraries (as you have found) for CMake-3 or CMake-2.8.12.2. However, for the CMake-3 case there our warnings about the exact CMake code logic that enforces transitive versus non-transitive linking for the -DBUILD_SHARED_LIBS=ON case (but not -DBUILD_SHARED_LIBS=OFF) so for the -DBUILD_SHARED_LIBS=ON case I highly recommend you stick with cmake-2.8.12.2 which is known to give correct linking results with our current build system on Windows (and all other platforms). > [...]Thanks again for all your help Alan - sorry if my last email sounded a bit grumpy. You are welcome, and I also sometimes get grumpy at the "wild west" atmosphere of free software on Windows, but I think Cygwin and MinGW-w64/MSYS2 are turning that around. I saw your two commits on the git push feed, and I am about to test them on Linux both normally and also for the special case where I will create a blank-separated install path for the Tcl/Tk components. While I am doing that, would you be willing to test the default case (i.e., without -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON) for CMake-2.8.12.2 (see above) as well? Even a quick and dirty result with all PLplot components disabled that you find depend on the CMake-3 version of find modules would be worthwhile. I understand why for your personal use you like to use the above options and CMake-3's version of find modules, but a test without those options and with CMake-2.8.12.2 would be a big help from the point of view of nailing down some Tcl and blank-separated answers for the PLplot build system in the default case for your platform. 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-08-31 22:24:34
|
Hi Alan I think we both are correct in terms of how libs are linked in both the Linux and Windows world. However I am not entirely sure that on Windows CMake is doing what you think it is doing. Just so you know on Windows the additional libraries do not get linked into the plplot library. However, when the examples are built, CMake remembers what the additional libraries are and links them into the example executables. When I want to link another executable with Plplot I have to link all the various dependacies separately. This is the case with all versions of CMake I have ever used. If this is the intended behaviour then all is fine - if not, then well it still works so isn't a big deal I guess. Re testing with the other settings. I will try - however it will be a very minimal build as I only have static libs linked against the static runtime for all the libraries I have built from source. I actually don't know how the Tcl libraries were built as I downloaded a binary installer, so I'm not sure how they will link. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: Arjen Markus <arj...@de...>; PLplot development list <plp...@li...> Sent: Sunday, 31 August 2014, 17:55 Subject: Re: [Plplot-devel] tcl build problem On 2014-08-31 00:37-0700 phil rosenberg wrote: > So on Windows either is acceptable - at least for static libs, dlls are a bit different. I can either link a library into a depending library then link this into my exe, or I can not link the libraries together and can link them all into the exe. Actually, I completely screwed up my explanation of transitive versus non-transitive linking. That consideration is only appropriate for the -DBUILD_SHARED_LIBS=ON case and is ignored in the -DBUILD_SHARED_LIBS=OFF case you were testing. Your remarks about static linking for Windows agree with what I think goes on for that case on Linux as well. My understanding is a static library on any platform is essentially just a collection of object code ready to be inserted into another library or else an executable _at link time_ (as opposed to being loaded at run time which is what happens with shared libraries). So if you link plplot with a static library, the relevant parts of that static library (those that satisfy some/all of plplot's of unresolved symbols) get inserted into the plplot library. So far so good, but if you forget to do that (which I think would generally be a poor choice), then the executable inherits those undefined symbols and you have one last chance to insert the static library's code into that executable. Note, that for the PLplot build system we have adopted the choice where target_link_libraries mentions _just_ the libraries that are needed because they satisfy unresolved symbols that are directly required by the particular library or executable being linked). So if a library or executable has a direct requirement we mention it but otherwise not. This should be perfect from the point of view of static libraries (as you have found) for CMake-3 or CMake-2.8.12.2. However, for the CMake-3 case there our warnings about the exact CMake code logic that enforces transitive versus non-transitive linking for the -DBUILD_SHARED_LIBS=ON case (but not -DBUILD_SHARED_LIBS=OFF) so for the -DBUILD_SHARED_LIBS=ON case I highly recommend you stick with cmake-2.8.12.2 which is known to give correct linking results with our current build system on Windows (and all other platforms). > [...]Thanks again for all your help Alan - sorry if my last email sounded a bit grumpy. You are welcome, and I also sometimes get grumpy at the "wild west" atmosphere of free software on Windows, but I think Cygwin and MinGW-w64/MSYS2 are turning that around. I saw your two commits on the git push feed, and I am about to test them on Linux both normally and also for the special case where I will create a blank-separated install path for the Tcl/Tk components. While I am doing that, would you be willing to test the default case (i.e., without -DBUILD_SHARED_LIBS=OFF -DSTATIC_RUNTIME=ON) for CMake-2.8.12.2 (see above) as well? Even a quick and dirty result with all PLplot components disabled that you find depend on the CMake-3 version of find modules would be worthwhile. I understand why for your personal use you like to use the above options and CMake-3's version of find modules, but a test without those options and with CMake-2.8.12.2 would be a big help from the point of view of nailing down some Tcl and blank-separated answers for the PLplot build system in the default case for your platform. 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-09-01 07:40:45
|
Hi Phil, The Tcl installation should come with files such as tclConfig.sh - these contain the compile and link information that you are currently missing. Regards, Arjen From: phil rosenberg [mailto:phi...@ya...] Sent: Monday, September 01, 2014 12:24 AM To: Alan W. Irwin Cc: Arjen Markus; PLplot development list Subject: Re: [Plplot-devel] tcl build problem Hi Alan I think we both are correct in terms of how libs are linked in both the Linux and Windows world. However I am not entirely sure that on Windows CMake is doing what you think it is doing. Just so you know on Windows the additional libraries do not get linked into the plplot library. However, when the examples are built, CMake remembers what the additional libraries are and links them into the example executables. When I want to link another executable with Plplot I have to link all the various dependacies separately. This is the case with all versions of CMake I have ever used. If this is the intended behaviour then all is fine - if not, then well it still works so isn't a big deal I guess. Re testing with the other settings. I will try - however it will be a very minimal build as I only have static libs linked against the static runtime for all the libraries I have built from source. I actually don't know how the Tcl libraries were built as I downloaded a binary installer, so I'm not sure how they will link. 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: Alan W. I. <ir...@be...> - 2014-08-31 23:32:15
|
On 2014-08-31 15:24-0700 phil rosenberg wrote: > Re testing with the other settings. I will try Thanks. That would be worthwhile now just to satisfy my curiosity about whether you get a limited PLplot version in that case. I predict you won't (see below), but seeing is believing.... > - however it will be a very minimal build as I only have static libs linked against the static runtime for all the libraries I have built from source. I actually don't know how the Tcl libraries were built as I downloaded a binary installer, so I'm not sure how they will link. This is case (2), external libraries other than the run-time. In this case for both the -DBUILD_SHARED_LIBS=ON and OFF cases, CMake should just link plplot and the plplot device driver DLL's with the external libraries that CMake finds (whether they are shared or static). So for the default -DBUILD_SHARED_LIBS=ON case you should have just as complete a PLplot as for your current -DBUILD_SHARED_LIBS=OFF case, but if not, let me know because I would be extremely surprised by that result. Just FYI, if CMake has a choice of shared or static library to be found, by default it will pick the shared one, and the result will be our build system will link plplot and the device drivers with shared external libraries. However, it doesn't sound like that is relevant to your case where only the static version of most/all external libraries needed by PLplot is available. Meanwhile, I have done some testing of the "blank-in-pathname" case on Linux and some additional changes beyond what you did are needed even in the Tcl/Tk case. For example, Itcl/Itk version testing was giving incorrect results until I found a fix. I am still in the middle of this and will likely not finish today, but I will give you some notice when I think all Tcl-related "blank-in-pathname" issues are fixed, and it is that stage repeating all your tests (both -DBUILD_SHARED_LIBS=ON and -DBUILD_SHARED_LIBS=OFF) on the VS/Windows platform would be quite valuable as well. But that is just the deal with the testing game; tests have to be repeated again and again. So the best advice I can give you is automate everything so you know you are doing the exact same test each time, and also as a matter of convenience so the repeat tests are trivial for you. 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-09-01 18:08:47
|
On 2014-08-31 16:32-0700 Alan W. Irwin wrote: > Meanwhile, I have done some testing of the "blank-in-pathname" case > on Linux and some additional changes beyond what you did are needed even > in the Tcl/Tk case. Those changes have now been pushed (commit dc5286a). They pass the new test_tcl and test_tk build and run-time test targets for the build tree for the case where -DBUILD_SHARED_LIBS=ON and where Tcl/Tk/Itcl/Itk install locations contain a blank in their path names, I now plan to do a comprehensive run-time test using scripts/comprehensive_test.sh for the same Tcl/Tk/Itcl/Itk install locations, and such a comprehensive test (involving run-time tests of both the build tree and install tree for our 3 major build configurations) will almost guarantee finding more changes that have to be done for our three different build systems (core build + CMake-based and traditional build systems for the installed examples). It's up to you whether you immediately build-test commit dc5286a with both -DBUILD_SHARED_LIBS=ON and OFF or wait for my final commit of changes to get comprehensive testing to work when Tcl/Tk/Itcl/Itk install locations have a blank in their path names, but in any case you should automate your build tests (or else put MSYS on your PATH so scripts/comprehensive_test.sh works for you) so it is convenient to repeat your tests at any time as more changes get pushed by any of us. 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-09-04 20:51:07
|
On 2014-09-01 11:08-0700 Alan W. Irwin wrote: > I now plan to do a comprehensive run-time test using > scripts/comprehensive_test.sh for the same Tcl/Tk/Itcl/Itk install > locations, and such a comprehensive test (involving run-time tests of > both the build tree and install tree for our 3 major build > configurations) will almost guarantee finding more changes that have > to be done for our three different build systems (core build + > CMake-based and traditional build systems for the installed examples). That prediction was spot on, and over the last few days I have been plugging away at all the issues that were found by that comprehensive testing. Today I finally got a breakthrough on what had been an intractable problem (dealing with blanks in pathnames for the Makefile + pkg-config traditional build system for the installed examples). Propagating that solution from one of our libraries to the rest requires extensive and non-trivial build-system changes that all need to be comprehensively tested, but I think the end is finally in sight, so I might even get this pushed by late Friday. 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-09-05 11:40:17
|
On 2014-09-04 13:51-0700 Alan W. Irwin wrote: > On 2014-09-01 11:08-0700 Alan W. Irwin wrote: > >> I now plan to do a comprehensive run-time test using >> scripts/comprehensive_test.sh for the same Tcl/Tk/Itcl/Itk install >> locations, and such a comprehensive test (involving run-time tests of >> both the build tree and install tree for our 3 major build >> configurations) will almost guarantee finding more changes that have >> to be done for our three different build systems (core build + >> CMake-based and traditional build systems for the installed examples). > > That prediction was spot on, and over the last few days I have been > plugging away at all the issues that were found by that comprehensive > testing. Today I finally got a breakthrough on what had been an > intractable problem (dealing with blanks in pathnames for the Makefile > + pkg-config traditional build system for the installed examples). > > Propagating that solution from one of our libraries to the rest > requires extensive and non-trivial build-system changes that all need > to be comprehensively tested, but I think the end is finally in sight, > so I might even get this pushed by late Friday. Hi Phil: Actually, I just made that push (commit 6f7f855) a little ahead of my ETA. This should complete my project to get comprehensive run-time testing (done with the scripts/comprehensive_testing.sh script) to work completely on Linux for a test case where Tcl/Tk/itcl/itk/iwidgets were installed with a pathname prefix that had a blank. This should clear out many of the blank-in-path issues that would have hindered you for your own comprehensive run-time testing. @everyone: As part of these series of commits I also took the opportunity to remove all mention of the unused LIB_TAG variable from our build-system logic. This change makes that logic much easier to read. 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-08-29 23:17:33
|
Thanks Alan. I'll have a look at that over the weekend. But just so you know in both the static and dynamic build case the libraries are not linked into the plplot library. If I create a program and link in Plplot, then I must separately link all the libraries that Plplot uses. This is the case also for the examples. I can view the properties of each example project in visual studio and see the libraries that are linked in - which is Plplot and all the inherited dependencies. I'm not sure if this static behaviour is the same on linux - it's obviously much less common to link statically on that OS. Anyway. Have a good weekend. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 29/08/2014 20:12 To: "Phil Rosenberg" <phi...@ya...> Cc: "PLplot development list" <plp...@li...> Subject: RE: [Plplot-devel] tcl build problem On 2014-08-29 18:22+0100 Phil Rosenberg wrote: > Hi Alan > Got both your messages. Unfortunately that cannot be where the external libraries are linked into the examples as I am building static libraries so almost that entire file (including the section you indicated) is skipped. > Just to be clear, Plplot itself is building fine, the linker error is when building the examples. When the plplot library is built as a static library, the devices are no longer independent DLL's, and instead the device code is inserted into the plplot library so all device compile flags and link flags need to be accumulated for that library. Of course, that is pretty difficult to get all that implemented correctly because of the large number of device drivers with many different dependencies so note my remarks below about also testing the default shared plplot library/dynamic devices case. The relevant CMake logic for the static plplot library case is in src/CMakeLists.txt (where the plplot library build is configured). In that case look for else(ENABLE_DYNDRIVERS) list(APPEND libplplot${LIB_TAG}_LINK_LIBRARIES ${DRIVERS_LINK_FLAGS}) [...] endif(ENABLE_DYNDRIVERS) [...] #message(STATUS #"libplplot${LIB_TAG}_LINK_LIBRARIES = ${libplplot${LIB_TAG}_LINK_LIBRARIES}" #) target_link_libraries( plplot${LIB_TAG} ${libplplot${LIB_TAG}_LINK_LIBRARIES} ) You should uncomment that message command to look at the CMake list in libplplot${LIB_TAG}_LINK_LIBRARIES to see if there is anything strange there in the static libraries case. Of course, you have stated that the static plplot library is building OK, but the trouble you are having with example builds may originate in how that library is built. What you said before about the extra .lib issue was 'This allows me to compile, but I am getting linker errors in the examples, because the linker flags are ending up as "C:/Program Files/Tcl/lib/tcl86.lib".lib' To proceed further I need complete information. Therefore, please send the usual that I always request for a complete bug report: cmake version, complete cmake options used, complete output from cmake command starting from initially empty build tree, complete (VERBOSE=1) output from (n)make command, CMakeCache.txt file. The first two items you can send just as part of the main text part of your next post here, but the remaining items should be packed into a compressed tarball or zip file and attached to that same post. Here are some further possibilities to consider: Use CMake-2.8.12.2 and the NMake generator (for the reasons I gave before). Also, the static plplot library case is not nearly as well debugged for our build system as the default shared libraries/dynamic devices case. Therefore, I would also try that default case (which would be an additional valuable test of building the Tcl/Tk bindings for your platform). Of course, remember to use the -DTEST_DYNDRIVERS=OFF workaround that is normally required for this case on Windows (to avoid doing the simple test of dynamic devices that fails on Windows when the same test with essentially the same code succeeds when run from the plplot library on Windows! Go figure....) 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-08-30 02:23:43
|
Hi Phil: On 2014-08-30 00:17+0100 Phil Rosenberg wrote: > Thanks Alan. I'll have a look at that over the weekend. But just so you know in both the static and dynamic build case the libraries are not linked into the plplot library. Yes, -DBUILD_SHARED_LIBS=ON or OFF (to use CMake terminology) either builds PLplot libraries as shared libraries and devices as independent shared DLL's or as static libraries (where the devices become part of the core library). But this CMake option says nothing at all about how external libraries are linked or whether the shared or static run time is used. > If I create a program and link in Plplot, then I must separately link all the libraries that Plplot uses. This is the case also for the examples. I can view the properties of each example project in visual studio and see the libraries that are linked in - which is Plplot and all the inherited dependencies. I'm not sure if this static behaviour is the same on linux - it's obviously much less common to link statically on that OS. There are three separate library linking issues. (1) linking PLplot libraries themselves (and only those libraries) as shared or static using BUILD_SHARED_LIBS to control that aspect; (2) linking external libraries (other than the run-time) as shared or static; and (3) using a shared or static run-time. On Linux and MinGW/MSYS/Wine I just take the default shared for (2) and (3) with no linking or run-time issues for both BUILD_SHARED_LIBS values. Of course, in the MinGW/MSYS/Wine case I have to be careful that the relevant external DLL's are on my PATH and similarly for the internal (PLplot) DLL's. Arjen's testing of Cygwin _and also_ MSVC with nmake has had similar success just using the default shared for (2) and (3). So I don't think you are going to run into trouble with MSVC and nmake by taking that same approach. If you look up the google terms <cmake force static> you will see that typically users get into a world of hurt by attempting static versions of (2) and (3). Static (2) is tricky because, for example, all external static libraries have to be mentioned in the right order. Years ago I tried that with PLplot (with one of our ancient build systems) and eventually got it to work, but it was painful so I have never tried static (2) again because it was so much trouble. I think static (3) is easier, but I have never tried it because I don't see the point unless (2) is static as well. All of this is, of course, a side issue to that one remaining .lib.lib linking issue, but I hope your full bug report will help me figure out that issue. 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-09-01 12:25:27
|
Cheers Arjen I remember having some problems with nmake and the 64 bit and 32 bit developer command lines, but I can't remember what the results were. As I only use the visual studio generators it's not imperative for me that this gets dealt with. I was only using nmake so Alan could get some extra debug info. Phil -----Original Message----- From: "Arjen Markus" <Arj...@de...> Sent: 01/09/2014 08:38 To: "phil rosenberg" <phi...@ya...> Cc: "PLplot development list" <plp...@li...> Subject: RE: [Plplot-devel] tcl build problem Hi Phil, I have given this matter some more thought, as the problem did seem familiar. If I remember correcrly, I have seen it as a consequence of a mixup of nmake with gcc or something similar. I will try and reproduce it. Regards, Arjen From: Arjen Markus [mailto:Arj...@de...] Sent: Sunday, August 31, 2014 3:30 PM To: Alan W. Irwin; phil rosenberg Cc: PLplot development list Subject: Re: [Plplot-devel] tcl build problem Hi Phil, Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, August 30, 2014 9:08 PM > > > 2) I tried using the nmake generator. It failed. It tried to build a > test program to test the compiler, which failed - cl.exe reported "could not find > kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. > This is obviously ridiculous as I clearly have a working c compiler. > > Can't help you there, but I bet Arjen can since he routinely uses the nmake generator > without such issues. > A missing kernel32.lib is very strange: it is one of the system libraries and it is used in just about any program. What happens if you compile a simpel C program manually: cl dummy.c? > > 3) I unfortunately don't have time to start fighting with the NMake > generator so I am returning back to the visual studio generator. > > Fair enough. I should tone down the negative things I said about the visual studio > generators since you obviously got one of them to work. > > But I will say this: there are lots of such visual studio generators and at least one new > one each year so CMake development resources to flush out the bugs are spread > thin. In comparison nmake has been around forever so that generator is completely > mature. Also, in your case the VS generator worked, but that may be because it is > relatively mature, and when you update your VS version you will also have to update > to a newer VS generator to be consistent with it. So in that case you might run into > issues for a while until the genrator matures. > Therefore, in my view it is always worthwhile to have the nmake generator available > so I hope Arjen responds above to get you squared away with nmake to use as a > reliable fallback when needed. > I find the variety of generators confusing myself. Especially since the version numbers/names of the various VS’s are confusing too. > > In the long term, the solution is for a volunteer or group of such volunteers to create a > free software distribution for Windows that enforces a self-consistent set of > packaging rules for each free software package that is included in that particular > distro. Cygwin is already one such effort (in this case backed by RedHat rather than > volunteers), and MinGW-w64/MSYS2 is another such distribution that has been put > together quite recently by volunteers and is rapidly gaining mindshare. So if this and > similar volunteer efforts continue to expand, the known current issues with binary > distribution of individual packages on Windows should eventually no longer be of > concern. > That is definitely a worthwhile goal – I know some people are awed by the complexity of building third-party software and therefore decide against using it. This is more important on Windows than on Linux. The “wild west” situation Alan describes is one of the culprits. 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. 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: Arjen M. <Arj...@de...> - 2014-09-01 12:29:24
|
Hi Phil, Yes, mixing 64-bits and 32-bits is something you need to avoid. I remember having trouble somewhere along the line where Cmake was picking up different versions than I expected. Or something like that. Well, I will try and see about nmake anyway, but there is no big hurry. That is good to know. Regards, Arjen From: Phil Rosenberg [mailto:phi...@ya...] Sent: Monday, September 01, 2014 2:25 PM To: Arjen Markus Cc: PLplot development list Subject: RE: [Plplot-devel] tcl build problem Cheers Arjen I remember having some problems with nmake and the 64 bit and 32 bit developer command lines, but I can't remember what the results were. As I only use the visual studio generators it's not imperative for me that this gets dealt with. I was only using nmake so Alan could get some extra debug info. Phil ________________________________ From: Arjen Markus<mailto:Arj...@de...> Sent: 01/09/2014 08:38 To: phil rosenberg<mailto:phi...@ya...> Cc: PLplot development list<mailto:plp...@li...> Subject: RE: [Plplot-devel] tcl build problem Hi Phil, I have given this matter some more thought, as the problem did seem familiar. If I remember correcrly, I have seen it as a consequence of a mixup of nmake with gcc or something similar. I will try and reproduce it. Regards, Arjen From: Arjen Markus [mailto:Arj...@de...] Sent: Sunday, August 31, 2014 3:30 PM To: Alan W. Irwin; phil rosenberg Cc: PLplot development list Subject: Re: [Plplot-devel] tcl build problem Hi Phil, Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, August 30, 2014 9:08 PM > > > 2) I tried using the nmake generator. It failed. It tried to build a > test program to test the compiler, which failed - cl.exe reported "could not find > kernel32.lib." Therefore as CMAKE was unable to find a working c compiler it exited. > This is obviously ridiculous as I clearly have a working c compiler. > > Can't help you there, but I bet Arjen can since he routinely uses the nmake generator > without such issues. > A missing kernel32.lib is very strange: it is one of the system libraries and it is used in just about any program. What happens if you compile a simpel C program manually: cl dummy.c? > > 3) I unfortunately don't have time to start fighting with the NMake > generator so I am returning back to the visual studio generator. > > Fair enough. I should tone down the negative things I said about the visual studio > generators since you obviously got one of them to work. > > But I will say this: there are lots of such visual studio generators and at least one new > one each year so CMake development resources to flush out the bugs are spread > thin. In comparison nmake has been around forever so that generator is completely > mature. Also, in your case the VS generator worked, but that may be because it is > relatively mature, and when you update your VS version you will also have to update > to a newer VS generator to be consistent with it. So in that case you might run into > issues for a while until the genrator matures. > Therefore, in my view it is always worthwhile to have the nmake generator available > so I hope Arjen responds above to get you squared away with nmake to use as a > reliable fallback when needed. > I find the variety of generators confusing myself. Especially since the version numbers/names of the various VS’s are confusing too. > > In the long term, the solution is for a volunteer or group of such volunteers to create a > free software distribution for Windows that enforces a self-consistent set of > packaging rules for each free software package that is included in that particular > distro. Cygwin is already one such effort (in this case backed by RedHat rather than > volunteers), and MinGW-w64/MSYS2 is another such distribution that has been put > together quite recently by volunteers and is rapidly gaining mindshare. So if this and > similar volunteer efforts continue to expand, the known current issues with binary > distribution of individual packages on Windows should eventually no longer be of > concern. > That is definitely a worthwhile goal – I know some people are awed by the complexity of building third-party software and therefore decide against using it. This is more important on Windows than on Linux. The “wild west” situation Alan describes is one of the culprits. 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. 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. 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. |