On 2014-03-14 12:36-0700 Alan W. Irwin wrote:

> Just to remind all of you, the fundamental purpose of epa_build on all
> platforms is to first build all the PLplot dependencies (especially
> useful on Windows, but also useful on Linux and Mac OS X), and then
> finally build and comprehensively test PLplot in a standard way to
> check for any PLplot regressions that might have been introduced
> during a release cycle, check PLplot against the latest versions of
> its dependencies, etc.
>
> Andrew Ross and I have had good success with epa_build on Linux, and I
> have also recently had complete success with the plplot_lite variant
> of PLplot (i.e., with octave, wxwidgets, pango/cairo, and qt4_lite
> dependencies dropped) on Windows (MinGW/MSYS/Wine).  But there are
> still some epa_build limitations which I list below.  (I am working on
> the first two of these as part of my current agenda, but all the rest
> are up for grabs.)
>
> * The wxwidgets epa_build configuration is fine on the Windows side of
> things but still a work in progress on the Unix side because I haven't
> figured out exactly which subset of the GTK stack of libraries needs
> to be built to satisfy the Unix side dependency of wxwidgets on GTK.

Hi Phil:

That wxwidgets dependency turned out to be essentially the complete
stack of GTK libraries (gtk+ and all its dependencies including the
pango/cairo subset of those dependencies which has already been
epa_build configured and tested).  Therefore, I have updated the
procedure documented in cmake/epa_build/README.developers to
automatically generate epa_build configurations for gtk+ (not just tne
pango/cairo subset of that which was used before) and its
dependencies on Unix.  As of revision 13078 those new epa_build
configurations have been sucessfully build tested on Linux using the
build_wxwidgets target (which includes all the epa_builds of all its
dependencies including gtk+ and its dependencies).  (Those extra gtk+
dependencies of wxwidgets do not have to be built on the Windows side
of things so for that case wxwidgets does not have a dependency on
gtk+).

When I tried this with an epa_build of 2.8.12 (which had long worked
for me with the system version of gtk+2 if I did not epa_build the
pango/cairo subset of gtk+3 which was needed for our cairo device
driver), the epa_build of wxwidgets against the epa_build of a
complete gtk+3 was fine, but I got a bunch of run-time errors with
PLplot's wxwidgets device drivers.  I then
discovered with a google search that old versions of wxwidgets like
this are not compatible with gtk+3 (the version built by epa_build).
So I upgraded the epa_build of wxwidgets to 3.0.0 (which is compatible
with gtk+3).  That turned up a build bug for that version which is
that a build with a separate build tree no longer builds properly.

Would you be willing to verify this wxwidgets-3.0.0 build issue
on Windows and report it to wherever wxwidgets bugs should be
reported? The error message I got with a separate build tree for
wxwidgets-3.0.0 was

make[4]: *** No rule to make target
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_wxwidgets/lib/wx/include/gtk2-unicode-debug-2.8/wx/setup.h',
needed by wxregex_regcomp.o'.  Stop.

I could get by that one by disabling unicode, but then further down
the line in the build another error concerning a missing setup.h
showed up.

Adding "BUILD_IN_SOURCE 1" appropriately in
cmake/epa_build/wxwidgets/CMakeLists.txt (as of revision 13080) which
forces a build in the source tree solved
those build issues completely.

The current set of configure options I use there (besides --prefix) is
--enable-shared --enable-unicode --enable-debug --enable-debug_gdb
--with-gtk=3

Are there any further configure options you would recommend for the
epa_build of wxwidgets-3.0.0?

The epa_build of gtk+ requires 23 minutes on my 5-year old PC, and the
further wxwidgets build after that takes an additional 13 minutes.  So
doing all this with epa_build rather than some downloaded binary
version is quite practical on Linux.  And for the Windows case, the
gtk+ build is not necessary so the complete epa_build of wxwidgets
should be considerably faster than ~36 minutes.

There are at least two run-time issues on Linux with an epa_built version of
PLplot, wxwidgets-3.0.0, and gtk+-3.9.8.

(1) Strange dbus warning message.

wine@raven> examples/c/x01c -dev wxwidgets
PLplot library version: 5.10.0

** (x01c:5554): WARNING **: Error retrieving accessibility bus
address: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.a11y.Bus was not provided by any .service files

This WARNING message appears every time I use -dev wxwidgets
for any of the standard examples.

Note this is a Linux-only issue since dbus is a (system) dependency of
gtk+ which in turn is a dependency of wxwidgets.  But on Windows,
gtk+ is not a dependency of wxwidgets so dbus is not a factor.

Can you try to confirm this issue on Linux?

(2) Really, really! strange run-time "forced mousing" issue for -dev
wxwidgets for some but not all examples

examples/c/x17c -dev wxwidgets

generates the above peculiar WARNING message and the plot hangs
immediately.  I then discovered by accident that if I move the mouse
in the wxwidgets GUI, the example proceeds, but if I ever quit moving
it, the plot halts again!  So the computer is forcing me to constantly
move the mouse in order to drive the plot to conclusion.

This issue occurs when I am remotely displaying and mousing on an X
terminal and when I am directly displaying and mousing. It also occurs
for both the basic case (-drvopt backend=0) and the wxGC case (-drvopt
backend=2).  (The agg case, -drvopt backend=1 is disabled in my
testing.) This issue only occurs for some of the examples.  For
example, standard example 1, 23, and 24 are fine (with unicode looking
great for the latter two), but standard example 8 (and 17) requires
forced mousing.

Can you try to confirm this forced mousing issue on Linux (and
possibly on Windows)? Note, I have not (yet) tried an epa_build of
wxwidgets-3.0.0 on MinGW/MSYS/Wine, but the corresponding epa_build of
wxwidgets-2.8.12 worked fine and also produced good run-time results
for the PLplot device driver on that platform.  So it seems likely
there won't be any epa_build issue for wxwidgets-3.0.0 on Windows.
And if the working hypothesis that this issue is caused by some
general (not just Linux-only) inconsistency between the PLplot
wxwidgets device driver code and wxwidgets-3.0.0 is correct, then you
should see this same strange run-time forced mousing issue as well on
Windows for standard example 17.

If others here have access to Linux system versions of wxwidgets-3.0.0
(as opposed to the epa_built version that I have access to) I would
also be interested in -dev wxwidgets results for that case. However,
if you do report such results, please use ldd to discover whether
wxwidgets-3.0.0 is linked with gtk version 2 or gtk version 3
libraries.  I am interested in reports for either of those cases, but
it is the latter case (implemented with epa_build) that I am reporting
above.

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
__________________________

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to