For CMake I use Cmake-gui
Now I'm working at office with windows 7-32 bits and msvc 2012.
Results are exactely like windows7-64 bits and msvc 2012-Win64:
no problem with static lib BUILD_SHARED_LIBS:BOOL=OFF. I can see
wxplotdemo running while building plplot
same problem with shared lib BUILD_SHARED_LIBS:BOOL=ON error LNK2001:
unresolved external symbol _plsc
command line for compile is :
/GS /TC /analyze- /W3 /Zc:wchar_t /I"D:\lib\test\plplot-plplot\include"
/I"D:\lib\test\plplot-plplot\buildshare\include"
/I"D:\lib\test\plplot-plplot\lib\qsastime" /Zi /Gm- /Od /Ob0
/Fd"test_plbuf.dir\Debug\vc110.pdb" /fp:precise /D "WIN32" /D "_WINDOWS"
/D "_DEBUG" /D "_CRT_SECURE_NO_DEPRECATE" /D "CMAKE_INTDIR=\"Debug\"" /D
"_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd
/Fa"Debug/" /nologo /Fo"test_plbuf.dir\Debug\"
/Fp"test_plbuf.dir\Debug\test_plbuf.pch"
Now If I add USINGDLL command line become :
/GS /TC /analyze- /W3 /Zc:wchar_t /I"D:\lib\test\plplot-plplot\include"
/I"D:\lib\test\plplot-plplot\buildshare\include"
/I"D:\lib\test\plplot-plplot\lib\qsastime" /Zi /Gm- /Od /Ob0
/Fd"test_plbuf.dir\Debug\vc110.pdb" /fp:precise /D "USINGDLL" /D "WIN32"
/D "_WINDOWS" /D "_DEBUG" /D "_CRT_SECURE_NO_DEPRECATE" /D
"CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /errorReport:prompt /WX-
/Zc:forScope /RTC1 /Gd /Oy- /MDd /Fa"Debug/" /nologo
/Fo"test_plbuf.dir\Debug\" /Fp"test_plbuf.dir\Debug\test_plbuf.pch"
And there is no problem.
Now I want to modify src/makelists.txt :
"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. "
I can open the file beginning by
"# src/CMakeLists.txt for PLplot
###
### Process this file with cmake to produce Makefile
###
# Copyright (C) 2006-2014 Alan W. Irwin
"
but how can I set COMPILE_DEFINITIONS?
At line 68-69 of CmakeLists.txt i can find
SET_SOURCE_FILES_PROPERTIES(${plplot_LIB_SRCS}
PROPERTIES COMPILE_FLAGS "-DUSINGDLL" )
but (may be I'm wrong) it's only for plplot_LIB_SRCS and test_plbuf.c
it's not in the list.
so how can i set COMPILE_DEFINITIONS for test_plbuf.c in cmakelists.txt?
Le 18/03/2015 07:47, Alan W. Irwin a écrit :
> 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
> __________________________
--
Laurent Berger
Enseignant-chercheur I.U.T. du Mans
Département Gestion des Entreprises et des Administrations
Département Mesures Physiques
Tél 02 43 83 37 09
------------------------------------------------------------------------------
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
