Hi Alan, Arjen
I've had some steps forward and some steps back on this. I'll try to go through
it all as logically as possible.
1) I tried commenting out the line as you suggested Alan - still got wxString
related linker errors. I then tried a fresh build using my patch and got the
same linker errors which makes me think that maybe the auto finding of
wxWidgets unicode libs never worked in the first place. I hunted through the
FindwxWidgets Cmake module and found that I can set the wxWidgets version to
compile against as part of the cmake command using
-DwxWidgets_CONFIGURATION=mswu. This solved all the wxString linker problems.
This works without commenting out the line you suggested so I think you can
commit your v2 patch Alan.
2) Unfortunately there is a big however tagged on the end of this. Although the
wxString linker errors were gone I had a series of additional linker errors
related to debug functions - similar but not quite the same as those reported
by Arjen. It took me some time to find the problem, but when I did find it I
realised I had seen the problem before but hadn't reported/documented it and
had forgotten about it. This problem exists irrespective of whether Alan's
patch is applied -i.e. it is a bug in the current source. The problem is that
in the release build the files wxwidgets.cpp, wxwidgets_agg.cpp,
wxwidgets_app.cpp, wxwidgets_dc.cpp, wxwidgets_dc.cpp, wxwidgets_gc.cpp and
wxPLplotDemo (but not wxPLplotstream.cpp or wxPLplotwindow.cpp) have DEBUG and
__WXDEBUG__ added to their preprocessor definitions. This causes the reported
link errors and deleting these options allows plplot to build. I'm pushing my
Cmake knowledge way past it's boundaries looking
into the cause of this. Do either of you have any ideas?
Phil
________________________________
From: Alan W. Irwin <[email protected]>
To: phil rosenberg <[email protected]>
Cc: Arjen Markus <[email protected]>; PLplot development list
<[email protected]>
Sent: Tuesday, 12 March 2013, 18:28
Subject: Re: [Plplot-devel] Notes on building the wxwidgets software package on
MinGW/MSYS
To Phil and Arjen:
I have read all your recent e-mails on this subject, and
here is a summary of where I think we stand.
@Arjen: I ascribe the symptoms you found for my original patch to the
static/dynamic inconsistency between the C and C++ run times caused by
the known issue with my original patch. So please try my latest patch
instead (and especially the variant of it I describe below).
> On 2013-03-12 12:08, phil rosenberg wrote:
>> Alan, regarding your patch - some good news and some bad. The
good news is that the patch now gives the correct flags to provide the
static build.
>> However the bad news is that it seems to have brocken
something in the wxwidgets cmake module. Previously I could use set
CXXFLAGS=/DUNICODE /D_UNICODE set CFLAGS=/DUNICODE /D_UNICODE
before calling cmake to use unicode. Now if i do this the unicode
option is still set in plplot, however the wxWidgets module no longer
finds the unicode version of the wxWidgets libraries so I get linker
errors for all the examples. This is because wxString is different for
unicode and non-unicode builds.
@Both:
Please try a variant of my latest patch with
set(${flag_var} "${${flag_var}}" CACHE STRING "Flags used by the
compiler" FORCE)
commented out in cmake/modules/plplot.cmake. That line
forces the cached form of those variables to have the same
contents as the uncached version, but I don't think that is
necessary, and forcing cached variables can have some
side effects (perhaps like Phil encountered above) which
we want to avoid.
The only downside of commenting out the above line that I am aware of
is a cosmetic one. With that line commented out, CMakeCache.txt will
contain the unchanged cached variables (with /MD rather than /MT) ,
and you will have to look at the exact commands generated by nmake at
run time to see whether the /MT flags have been applied properly in
all cases.
By the way, I think commenting out the above line will make my
patch equivalent to Phil's original patch (except that my
patch does the changes in the correct location so that the
logic doesn't have to be repeated for all the different subdirectories).
@Phil: so let me know if there is any difference at all between results
for my patch (with the above line commented out) and your original
patch.
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
