On 2013-03-14 11:32+0100 Arjen Markus wrote:
> Hi Alan, Phil,
>
> adding the option /D_ITERATOR_DEBUG_LEVEL=0 to the replacement string in
> plplot.cmake did get rid of the
> error messages about that mismatch, but now I am facing
> error messages about multiply defined symbols:
>
> test_plend.c
> Linking CXX executable test_plend.exe
> msvcprt.lib(MSVCP100.dll) : error LNK2005: "void __cdecl
> std::_Xlength_error(char const *)" (?_Xlength_error@std@@YAXPBD@Z) already
> defined in libcpmt.lib(xthrow.obj)
[...]
> Not quite sure how to proceed here. One option might be
> to force the linker to ignore these double definitions
> (/force option, IIRC), but it usually is a sign that
> potentially incompatible compile options have been used
> for different parts of the program.
>
> Does anyone have advice on this? (Linkage problems with
> C++ programs are a terra incognita for me ;))
One issue that completely surprises me is why in the world do the
MSVC/ifort set of compilers build the test_plend executable as
if C++ code (as opposed to plain C code) is involved?
The only CMake logic in examples/c/CMakeLists.txt relevant to that
question is
add_executable(test_plend test_plend.c)
target_link_libraries(test_plend plplot${LIB_TAG} ${MATH_LIB})
test_plend.c is obviously plain C, I assume that is also true for the
plplotd library, and ${MATH_LIB} should be empty on Windows.
I double-checked with both Linux and MinGW/Wine, and indeed test_plend
is built as C and not C++ on those platforms. So why is the above
build mistake ("Linking CXX executable test_plend.exe") being made for
the MSVC/ifort set of compilers?
Of course, C++ builds probably will be done in all cases if you are
using static device drivers because then all device driver code
including the C++ code for wxwidgets.cpp goes directly into libplplotd
for that case. I have always considered it to be problematic to mix C
and C++ code in the same library so eventually I intend to cure this
static device driver issue by making a separate C++ library for the
static C++ device drivers which libplplotd can link to for this
specific case. But this problematic build for the static device case
is a completely separate issue, and I assume you (like me on both my
gcc/Linux and MinGW/Wine platforms) are using the default dynamic
devices where any device drivers written in C++ (such as wxwidgets)
are built as separate DLL's which are dynamically loaded at run time
by libplplotd as needed.
Here are my suggestions for how you should proceed. For MSVC/ifort I
would double-check that ${MATH_LIB} is empty, and whether or not
plplot${LIB_TAG} is built as C or C++. If the latter, then with
VERBOSE=1 mode (or nmake equivalent) you should be able to find the
exact compile command being used to build each piece of libplplotd and
figure out how/why C++ code is contaminating that C library.
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
__________________________
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
