Given that the libraries in question are in the standard c and C++ libraries. I just tested to see what the impact is of simply commenting out the checks for these two libraries.
The result is that wingcc is accepted onto the driver list, appears in my plplot VC++ project, everything builds correctly and I can run the examples and select the wingcc device and everything runs fine. Given that this is the case is there even a need to check for these libraries? Or is this test needed for Cygwin or minGW builds? I also did a quick google and spotted this bug report https://cmake.org/Bug/view.php?id=15831. I think the gist of it is that find_library will only search in Windows SDKs that are at least as old as the one used to build that version of Cmake. This seems a bit daft to me as it forces upgrade whenever a new SDK is released - I know in the past Alan has mentioned the need to not upgrade due to a bug in a release, but that may not be an option if this is the case. Again maybe this suggests that we should simply not use find_library and simply assume that these libraries will be included in with the standard libraries. Phil On 5 October 2017 at 22:42, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2017-10-05 09:10+0100 Phil Rosenberg wrote: > >> On 5 October 2017 at 04:10, Alan W. Irwin <ir...@beluga.phys.uvic.ca> >> wrote: >>> >>> The cmake messages above come from cmake/modules/wingcc.cmake and the >>> first part of the relevant logic is >>> >>> find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH} >>> ${BORLANDLIBPATH}) >>> if(GDI32_LIBRARY) >>> find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH} >>> ${BORLANDLIBPATH}) >>> endif(GDI32_LIBRARY) >>> > >> gdi32.dll and comdlg32 are both in the standard system directory >> c:/windows/system32/ > > >>> If both those libraries are installed on your system but in a >>> non-standard location that CMake doesn't know about, then >>> you may have to give CMake a hint where they are by setting >>> CMAKE_LIBRARY_PATH appropriately. > > > Hi Phil: > > One thing I noticed from your previous post that included all the > information from cmake was your cmake version was 3.7.1. My impression > is there has been a lot of churn in the various Windows IDE generators > since 3.7.1 due to lots of bug fixing so this issue might be solved > simply by downloading and using the latest binary version of CMake > (3.9.4) directly from Kitware. > > But if you would prefer to stick to 3.7.1 for now or if 3.9.4 still > has the same symptoms, then from the above collection of information I > suggest you add c:/windows/system32/ to the CMAKE_LIBRARY_PATH > information you already have (on Linux the format is a colon-separated > list of library locations, but on Windows that may be a > semicolon-separated list), and I am virtually positive that will solve > the library finding issue for wingcc. And if you set -DPLD_wingdi=ON, > it should also solve it for wingdi (since that device uses the same > libraries and same library finding logic as wingcc). > > By the way I am virtually positive that if CMake cannot find these > standard system libraries in one of the expected standard locations > without user help via CMAKE_LIBRARY_PATH, then that is a clear CMake > bug (likely for the particular generator you are using). So if you > confirm that this bug still persists with 3.9.4 directly downloaded > from Kitware, then to help other users in your position, I plan to > follow up with the CMake developers about this bug, but before > starting that discussion I will need to know the exact > generator you are using for your Windows IDE. > > > 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 > __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
