Hi Alan Here are the tests I have performed. First I simply changed the generator to Visual Studio 14 Win64, then in the resulting solution I tried to build example 0.
This resulted in many version mismatch errors with wxWidgets, because wxWidgets was built with VS 2012. I rebuild with -DENABLE_wxwidgets=OFF. I then got two linking errors related to shapelib: 12>shapelib.lib(safileio.obj) : error LNK2019: unresolved external symbol __iob_func referenced in function SADError 12>shapelib.lib(shpopen.obj) : error LNK2019: unresolved external symbol _snprintf referenced in function SHPReadObject Again shapelib was built using Visual Studio 2012. So I added -DHAVE_SHAPELIB=OFF Now x00.exe builds fine. Note that both snprintf and _snprintf are listed as not found by cmake. But this isn't a blanket loss of the check_function_exists() function. isnan and isfinite are both found and I presume they use check_function_exists()? I then reread your email and found you provided a rather shorter test. I dumped this in a cmakelists.txt file and this could not find snprintf either I figured we can't be the only people having this issue so I googled it and found this page http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=15659&graph=relation It seems that snprintf and a number of other io related functions are now defined inline in stdio.h. This explains my linker errors above when shapelib was included - snprintf was not found because it is no longer in the library. The answer apparently is to use CheckSymbolExists instead. The following works correctly cmake_minimum_required(VERSION 2.8.9) project(test_check C) include(CheckSymbolExists) check_symbol_exists(snprintf stdio.h PL_HAVE_SNPRINTF) message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}") So this is really nothing to do with the new "Universal" nature of the CRT, it's just that the new CRT has inlined those particular functions. Alan I will leave you to integrate this how you see fit as I wouldn't know where to start. Phil On 3 September 2015 at 21:04, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > Hi Alan > Yes I have it installed, but haven't really tried it much yet (I was > lured into playing with its new ability to us it to debug on a Linux > machine using GDB via ssh) I will try a PLPlot build now and see what > happens. > > I have just read the link you provided. It is a useful mov they are > making. I personally always use static linking to the runtime so that > if I give an exe to someone else it will "just work" and there is no > need for them to install a visual studio runtime (which must be the > correct VS version). The move to including the runtime as part of the > OS is more like the way I think Linux works, and there everyone builds > using dynamic linking to the runtime with generally good result. > > I don't really understand what the implication is for snprintf or > check_function_exists(). Why would having the CRT as part of the OS, > rather than as an installed component make any difference? Is this a > CMAke bug rather than a PLPlot bug? > > Phil > > On 3 September 2015 at 18:46, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: >> To Phil, Jim, and Greg: >> >> Do any of you have access to VC14 (a.k.a Visual Studio 2015)? If so >> I need your Windows expertise for dealing with the bug report below >> which is likely the tip of the iceberg for a whole bunch of >> troubles with Windows linking for that platform. For example, >> I looked up Universal CRT, and found >> <http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx> >> which appears to say that linking should be different for VC14 and >> beyond. But if that is the case, the proper cure for this issue >> is to set one or more of >> >> CMAKE_REQUIRED_FLAGS = string of compile command line flags >> CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar) >> CMAKE_REQUIRED_INCLUDES = list of include directories >> CMAKE_REQUIRED_LIBRARIES = list of libraries to link >> >> appropriately before _all_ calls to check_* CMake functions such as >> the particular use of check_function_exists below. But I need your >> advice on what the values of the above variables should be for VC14 >> and beyond. >> >> To explore what is possible I recommend using some variant (with >> some of the above variables set) of the following test cmake >> mini-project. >> >> cmake_minimum_required(VERSION 2.8.9) >> project(test_check C) >> include(CheckFunctionExists) >> check_function_exists(snprintf PL_HAVE_SNPRINTF) >> message(STATUS "PL_HAVE_SNPRINTF = ${PL_HAVE_SNPRINTF}") >> >> This project gives good results, i.e., >> >> -- The C compiler identification is GNU 4.7.2 >> -- Check for working C compiler: /usr/bin/gcc >> -- Check for working C compiler: /usr/bin/gcc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Looking for snprintf >> -- Looking for snprintf - found >> -- PL_HAVE_SNPRINTF = 1 >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /home/irwin/test_cmake2/build_dir >> >> for me on Linux, and my question for you boils down to what values >> need to be assigned to the above variables so this mini-project also >> works (i.e., yields PL_HAVE_SNPRINTF = 1) on VC14 for the latest CMake >> version you have access to? >> >> By the way, our handling of the CMAKE_REQUIRED_* variables for the >> check_* CMake functions that we use is currently a mess, and I am in >> the process of fixing that. If your run of the above test for VC14 >> shows no CMAKE_DEFINED_* variables have to be set, then my fix will be >> the only required change. However, if CMAKE_DEFINED_* variables do >> have to be set in order for the above test to work, my fix will put me >> in a good position to use that information. >> >> 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 >> __________________________ >> >> ---------- Forwarded message ---------- >> Date: Thu, 03 Sep 2015 12:07:41 +0000 >> From: Torsten Martinsen <bullest...@users.sf.net> >> Reply-To: Ticket 179 <1...@bugs.plplot.p.re.sf.net> >> To: Ticket 179 <1...@bugs.plplot.p.re.sf.net> >> Subject: [plplot:bugs] #179 Detection of snprintf fails with VC14 >> >> >> >> >> --- >> >> ** [bugs:#179] Detection of snprintf fails with VC14** >> >> **Status:** open >> **Group:** >> **Labels:** vc14 >> **Created:** Thu Sep 03, 2015 12:07 PM UTC by Torsten Martinsen >> **Last Updated:** Thu Sep 03, 2015 12:07 PM UTC >> **Owner:** nobody >> >> >> Due to the Universal CRT introduced in VC14 (aka Visual Studio 2015), >> check_function_exists() no longer works for detecting the presence of >> snprintf(). This leads to a linker error when using the library. >> >> This patch fixed it for me: >> ~~~~ >> diff --git a/cmake/modules/plplot.cmake b/cmake/modules/plplot.cmake >> index 90aac62..7fea410 100644 >> --- a/cmake/modules/plplot.cmake >> +++ b/cmake/modules/plplot.cmake >> @@ -347,7 +347,11 @@ if(PL__HAVE_ISINF) >> endif(PL__HAVE_ISINF) >> >> >> -check_function_exists(snprintf PL_HAVE_SNPRINTF) >> +if(MSVC_VERSION EQUAL 1900) >> + set(PL_HAVE_SNPRINTF 1) >> +else(MSVC_VERSION EQUAL 1900) >> + check_function_exists(snprintf PL_HAVE_SNPRINTF) >> +endif(MSVC_VERSION EQUAL 1900) >> if(NOT PL_HAVE_SNPRINTF) >> check_function_exists(_snprintf _PL_HAVE_SNPRINTF) >> set(PL_HAVE_SNPRINTF ${_PL_HAVE_SNPRINTF} CACHE INTERNAL "Have function >> _sprintf") >> ~~~~ >> >> >> --- >> >> Sent from sourceforge.net because you indicated interest in >> <https://sourceforge.net/p/plplot/bugs/179/> >> >> >> >> To unsubscribe from further messages, please visit >> <https://sourceforge.net/auth/subscriptions/> ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
