Hi laurent: On 2015-03-18 03:56+0100 laurent Berger wrote:
[out of order] > With a no shared lib and with Windows 7-64 bits and MSVC 2012 Win64 bits: > //Build shared libraries > BUILD_SHARED_LIBS:BOOL=OFF > there is no error That good result makes sense because BUILD_SHARED_LIBS:BOOL=OFF means the static form of PLplot libraries is built where symbol visibility (e.g., whether plsc is externally accessible from the library) should not be an issue. However, if you are willing to help more with testing the MSVC 2012 Win64 bits shared libraries case until you are satisfied with it, then please read on.... > Now I forget MSVC 2013 > My cmake version is 3.1.2. See remarks below about CMake version. Also, could you let us know what CMake generator you are using? (Sorry, I forgot to ask for this key information before.) > I have build all versions DEBUG MinSizeRel Release RelWithDebInfo with > Windows 7-64 bits and MSVC 2012 Win64 bits > I have build too with Windows 7-64 bits but with MSVC 2012-32bits > CMakeCache.txt is > ******* > //Build shared libraries > BUILD_SHARED_LIBS:BOOL=ON > > Always results is >> test_plbuf.obj : error LNK2001: unresolved external _plsc > 1>F:\Lib\test\plplot-plplot\build2012-32\examples\c\RelWithDebInfo\test_plbuf.exe > > : fatal error LNK1120: 1 externes non résolus > Note the whole point of the USINGDLL macro for the shared library case is to sort out symbol visibility issues when the PLplot libraries are being built so because USINGDLL was not set my hypothesis was the plsc symbol was not visible ==> build error. For your first report of results, when USINGDLL was being set (#defined) when you built shared PLplot libraries you had success. Is that still _always_ the case? @Arjen, Phil, and Jim: If on the contrary laurent replies that shared library results are sometimes bad even when USINGDLL is set by hand, then you should step in to see whether you can confirm larent's bad results on your own MSVC platforms. @Laurent: However, if you confirm that shared library results are always good if USINGDLL is set by hand, then I can still likely help you (despite my inexperience with MSVC) because one of my key PLplot responsibilities is the build system, and the issue (assuming your confirmation) boils down to convincing our build system to set that macro properly for your MSVC platform case. (Note for the Linux, Cygwin, and MinGW/MSYS cases, our build system always sets USINGDLL whenever it is needed for the shared library case, and I need that to happen for the MSVC case as well. That's why I asked you to edit src/CMakeLists.txt in the source tree to try the alternative of setting the COMPILE_DEFINITIONS property, and, of course, that test should be run _without_ setting USINGDLL by hand, and for a completely new build with no stale results left over from an old build to confuse issues. Also, other experiments you should try (since Windows support is improving all the time for CMake-3.x.y) is to try the latest bugfixed version of CMake-3.1.y which is CMake-3.1.3 (not the CMake-3.1.2 version that you are currently using) according to <http://www.cmake.org/files/v3.1/> and also the latest bugfixed version of CMake-3.2.y which is CMake-3.2.1 according to <http://www.cmake.org/files/v3.2/>. And the same remarks apply for all tests concerning not setting USINGDLL by hand, and using a fresh build for each new experiment. Note that almost all of my recent Linux testing has been for CMake-3.0.2, but just now I did a quick check that our Linux build (and the test_noninteractive test of all our file devices) worked fine for CMake-3.2.1. Therefore, there is a good chance that CMake-3.2.1 will work as well as or better than CMake-3.1.3 on Windows, but you should try both versions to see if the USINGDLL problem goes away for either. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
