Hi Laurent,
Yes, in this case, because test_plbuf.c is using the Plplot stream from the
library _directly_ (the symbol plsc), it needs to be imported explicitly. One
way is to define the macro USINGDLL (which is intended for the language binding
libraries, but that is the same linker issue). I think that the macro should be
set in the source file test_plbuf.c directly - that way the burden is on this
test program.
Regards,
Arjen
> -----Original Message-----
> From: Laurent Berger [mailto:laurent.ber...@univ-lemans.fr]
> Sent: Wednesday, March 18, 2015 10:04 AM
> To: Alan W. Irwin
> Cc: Arjen Markus; Phil Rosenberg; Jim Dishaw; PLplot development list
> Subject: Re: [Plplot-devel] Call for testing of the PLplot git master tip
> version VS2012,
> shared libraries
>
> 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
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.
------------------------------------------------------------------------------
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
