On 2015-01-23 10:41-0000 Phil Rosenberg wrote:
Hi Alan
Thanks for your tests, they are very useful. I have made some further
changes and attached a new patch. As I know you like interleaved
posting so much I will try to go through point by point ;-)
Thanks for that kindness. :-)
Just as an experiment I attempted to build the wxwidgets device against version
2.8
of the external wxwidgets software
Yes I too was surprised to find that the code built with wxWidgets 2.8
on my work Linux machine, although it is here I get the missing
library runtime error. This machine also has the intel compiler and
CentOS, rather than gcc and Ubuntu. That said, it does have gcc, but
icc was being picked up by CMake and I couldn't seem to get it to
change. I had thought that wxGCDC which was needed to access
antialiased high quality graphics was a wxWidgets 2.9+ introduction,
but I was obviously mistaken. I have made an effort therefore to keep
the driver 2.8 compatible, given many academic users (including
myself) are probably using enterprise Linux which tend to use older
software versions.
In light of what you said above I will stick with 2.8 for now. Also, with
regard to
your gcc point, you can use the CC and CXX environment variables
_before_ you invoke cmake in an empty build directory, e.g.,
export CC="gcc -g"
export CXX="g++ -g"
to specify both compiler and compiler flags (if any).
sh: 1: wxPLViewer: not found
That issue is a build-system dependency issue, where to solve it
you need to add the line
add_dependencies(wxwidgets wxPLViewer)
Thanks Alan. I'm not entirely sure where to put this. The wxWidgets
driver code is included in the plplot library, so I feel wxPLViewer
needs to be a dependency of the plplot library.
CMake terminology for "dependency" is confusing here so you have to be
very precise in your mental model of what a CMake dependency means.
When target A depends on target B (as specified by add_dependencies(A
B)) that means B is always built first, i.e., it is a prerequisite of
A. So I think what you meant to say above is the target wxPLViewer
should depend on target plplot (i.e., the plplot library).
It turns out that dependency is enforced indirectly but not directly
(which is fine). The line
./utils/CMakeLists.txt: target_link_libraries(wxPLViewer
plplotwxwidgets plplotcxx ${wxwidgets_LINK_FLAGS} ${MATH_LIB})
automatically means that wxPLViewer depends on the targets
plplotwxwidgets (the wxwidgets binding for PLplot, libplplotwxwidgets)
and plplotcxx (the C++ binding for PLplot, libplplotcxx)), but not
directly on the target plplot (libplplot, our core C library), i.e., the
wxPLViewer source code directly refers to code both in
libplplotwidgets and libplplotcxx, but not to code in libplplot.
(You should double-check that conclusion is correct.) Of
course, in any case, libplplot will be built first because both the
plplotwidgets and plplotcxx targets depend on the plplot target.
If memory serves the wxwidgets device (i.e., the wxwidgets target)
already depends on libplplotwidgets. So we currently have two
independent dependency chains set up by our current build system; one
for the wxPLViewer target and one for the wxwidgets target. But it
appears that the wxwidgets device depends on the wxPLViewer utility to
work correctly. Therefore, the two independent dependency chains
should be merged together with
add_dependencies(wxwidgets wxPLViewer)
as I stated above. (This logic in no way conflicts with the existing
independent dependency chains. Instead, it simply insures that if the
user builds the wxwidgets target, that the wxPLViewer target will
always be built automatically first.)
To answer your question about the location of the above logic, you
will see in the top-level CMakeLists.txt file, that the drivers and
src subdirectories are processed before the utils directory so the
appropriate place to put that logic (inside a test whether the
wxwidgets target exists) is utils/CMakeLists.txt.
I have commited that change on my local wxwidgets topic branch and attach
the patch (created with
git format-patch --stdout -1 --start-number=38 -n >/tmp/wxAWI_addedpatch
)
Note that patch is just for my single commit and not for the whole
series of commits on the topic branch so you should be able to apply
it with "git am" on top of your own topic branch with no need to
select a patch using the -i option. The above --start-number=38 -n
options are just to remind you that I have applied it as the 38th
commit on my topic branch (i.e., after your 37 commits are applied to
create that topic branch), but that should not preclude you applying
it in some different order if you already have made some further
changes on your own topic branch.
Of course, you may just be tempted to type in this small change, but
please do not do that. It is important to continue our git knowledge
expansion by using git tools like git am to collaborate. Also, using
git am preserves credit for my first small contribution to this topic.
:-)
examples/c/x01c -dev wxwidgets
worked with no hangs or other obvious run-time issues like segfaults
Thanks for running that test. Would it be possible for you to try a
handful of other examples too? The hangs I got were generally
intermittent. Examples 3 and 4 were quite temperamental I seem to
remember.
Your recent commits to this topic did solve the memory management
issue at exit that was reported by valgrind. However, there appear to
still be lots of sources of allocated memory that need to be freed on exit.
software@raven> !valgrind
valgrind examples/c/x01c -dev wxwidgets
==7712== Memcheck, a memory error detector
==7712== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==7712== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7712== Command: examples/c/x01c -dev wxwidgets
==7712==
PLplot library version: 5.10.0
==7712==
==7712== HEAP SUMMARY:
==7712== in use at exit: 90,589 bytes in 255 blocks
==7712== total heap usage: 49,087 allocs, 48,832 frees, 34,890,762 bytes
allocated
==7712==
==7712== LEAK SUMMARY:
==7712== definitely lost: 88 bytes in 1 blocks
==7712== indirectly lost: 68 bytes in 2 blocks
==7712== possibly lost: 0 bytes in 0 blocks
==7712== still reachable: 90,433 bytes in 252 blocks
==7712== suppressed: 0 bytes in 0 blocks
==7712== Rerun with --leak-check=full to see details of leaked memory
==7712==
==7712== For counts of detected and suppressed errors, rerun with: -v
==7712== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
(From what you said, I think you are already aware of such issues from
your own debugging tools. However, let me remind you the issue may be
in version 2.8 of wxwidgets rather than in the wxwidgets-related
PLplot code so there may be nothing that you need to do here.)
I also tried similar valgring experiments with examples 0, 10, 2, 3 and 4 (the
first two are because those are such simple examples) with similar
results. They all
showed no memory management issues, and unfreed memory issues like
above. I think 10 rendered OK, but 0, 2, 3, and 4 (like 1) showed
substantial rendering issues (large parts of the plot missing
(examples 0, 1 and 4)
character alignment problems (example 2), and/or orientation of string
problems (example 3).
One extremely interesting result was for example 4 which segfaulted
when GUI->File->exit was executed despite no memory management issue
reported by valgrind. That is the first time I have ever seen valgrind
give 0 errors in the summary when a segfault occurred, and
I have no idea of how that is even possible.
However, gdb should be able to help you quickly find the
answer. To help you get started with that
I rebuilt from scratch using
CXXFLAGS=-g -lpthread
CFLAGS=-g -lpthread
FFLAGS=-g -lpthread
(the -lpthread option is needed in order for gdb to work for -dev
wxwidgets which apparently uses threading). You can also set the
-lpthread option with the CXX, CC, and FC environment variables.
Here was the initial (but currently rather uninteresting since I set no break
points) result from gdb.
software@raven> gdb examples/c/x04c
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/software/plplot/HEAD/build_dir/examples/c/x04c...done.
(gdb) run -dev wxwidgets
Starting program: /home/software/plplot/HEAD/build_dir/examples/c/x04c -dev
wxwidgets
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Segmentation fault
[Inferior 1 (process 14645) exited normally]
(gdb) quit
So this proves gdb works for this threaded case (it did not work at
all for me if I just used the -g compiler option). Setting some break
points in the wxwidgets code that is executed during exits should
quickly lead to the source of the segfault for example 4. However, I
leave that to you since you are more much more familiar with the
wxwidgets code than I am.
[...]So once I get to the bottom of the hangs I will try to sort out the
remaining rendering problems and memory leaks.
I did not experience any hangs myself so I suspect your hangs are due
to CMake picking a bad compiler by default on Ubuntu, but now you know
how to override that default (see above) and set up gdb (using the -g
-lpthread compile options for gcc, g++, and gfortran). Therefore,
once you do that, I assume the hangs will go away and you will be left
with "simple" segfaults like above to debug with gdb. I also
assume that example 4 is needed to trigger the segfault
because it likely sets up the PLplot pages in a valid but distinct
way from other examples which triggers the segfault because
of some minor deficiency in the current wxwidgets device code.
If you cannot get past the hangs on Ubuntu even when the gcc compiler
suite is used, then you have the options of (1) trying a different Linux
distribution or (2) helping me to navigate through your
your new wxwidgets implementation so I can debug it myself with
gdb. But I think option 2 would take much more of your time than
option 1, and let's hope option 1 isn't necessary 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
__________________________
From 04aeab2e1bda42d1aded10605c670de784ac6e7c Mon Sep 17 00:00:00 2001
From: "Alan W. Irwin" <air...@users.sourceforge.net>
Date: Fri, 23 Jan 2015 12:33:16 -0800
Subject: [PATCH 38/38] Build system:wxwidgets: make the wxwidgets target
depend on the wxPLViewer target
---
utils/CMakeLists.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/utils/CMakeLists.txt b/utils/CMakeLists.txt
index e903bda..448d27a 100644
--- a/utils/CMakeLists.txt
+++ b/utils/CMakeLists.txt
@@ -91,4 +91,8 @@ if(ENABLE_wxwidgets)
add_executable(wxPLViewer WIN32 ${wxPLViewer_SRCS})
target_link_libraries(wxPLViewer plplotwxwidgets plplotcxx
${wxwidgets_LINK_FLAGS} ${MATH_LIB})
install(TARGETS wxPLViewer DESTINATION ${BIN_DIR})
+ if(TARGET wxwidgets)
+ add_dependencies(wxwidgets wxPLViewer)
+ endif(TARGET wxwidgets)
+
endif(ENABLE_wxwidgets)
--
1.7.10.4
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
