On 2017-07-18 12:36-0000 Arjen Markus wrote:
I attach three tarballs, resulting from the comprehensive test
script on Cygwin and MinGW (interactive and non-interactive). Not all
is well with the non-interactive ones. On Cygwin it failed in the
install tree (no error message other than "there was an error"), on
MinGW in the non-dynamic case with an error message from gcc "Bad
address". Neither is something I can unravel at this moment (being
nearly off on a short holiday).
OK. All you need to know for now was I received those tarballs and
analyzed them, and you should skip the rest, and go enjoy your
holiday. :-)
But after your holiday you should look in detail at the results of
those analyses below.
I. The noninteractive comprehensive test for Cygwin.
* Find issues
My records indicate you last ran a comprehensive test for Cygwin on
2016-12-15. The options for that test were the same as the present
ones, and that script was a complete success. Those December results
for components that were present (as taken from
shared/noninteractive/output_tree/cmake.out) were as follows:
December results:
DRIVERS_LIST:
cairo;qt;mem;ntk;null;ps;psttf;svg;tk;tkwin;wingcc;wxwidgets;xfig;xwin
Disabled components:
ENABLE_ada: OFF
ENABLE_d: OFF
ENABLE_java: OFF
ENABLE_ocaml: OFF
ENABLE_octave: OFF
ENABLE_pdl: OFF
ENABLE_pyqt5: OFF
In comparison, the current results for the same quantities are as
follows:
DRIVERS_LIST:
cairo;qt;mem;ntk;null;ps;psttf;svg;tk;tkwin;wingcc;xfig;xwin
Disabled components:
ENABLE_ada: OFF
ENABLE_d: OFF
ENABLE_java: OFF
ENABLE_ocaml: OFF
ENABLE_octave: OFF
ENABLE_pdl: OFF
ENABLE_python: OFF
ENABLE_pyqt4: OFF
ENABLE_pyqt5: OFF
ENABLE_itcl: OFF
ENABLE_itk: OFF
ENABLE_wxwidgets: OFF
So the changes from December are the wxwidgets device driver is not present
and there is also a severe regression in enabled bindings.
Is this exactly the same Cygwin system and launch script that you used
before when testing just before the release of PLplot-5.12.0? If so, you
should be able to
replicate those good December results by switching to PLplot-5.12.0
(e.g., by running
git checkout plplot-5.12.0
) before running your launch script. If you can replicate those
good past find results, then obviously there are find issues that have
been introduced for the PLplot master branch version that
we have to fix for the Cygwin case.
* Build error in the CMake-based build tree for the installed examples
This did not occur for the December test which was a complete success so
it will be interesting to see if this build error was present for
the plplot-5.12.0 test I suggested above.
The following results:
irwin@raven> grep Built
shared/noninteractive/output_tree/installed_make_noninteractive.out
[ 0%] Built target ext-cairo-test
[ 0%] Built target test_extcairo
[ 1%] Built target x21c
[ 1%] Built target x32c
[ 1%] Built target x31c
[ 2%] Built target x29c
[ 2%] Built target x28c
[ 4%] Built target x27c
[ 4%] Built target x33c
[ 4%] Built target x25c
[ 5%] Built target x24c
[ 7%] Built target x09c
[ 8%] Built target x16c
[ 8%] Built target x08c
[ 9%] Built target x07c
[ 11%] Built target x15c
[ 11%] Built target x23c
show many of the C examples built without issues for this case before the build
error for x04c.c that was encountered. And as you said, there is
a non-zero return code for that build command as indicated by
make[3]: *** [c/CMakeFiles/x04c.dir/build.make:104: c/x04c.exe] Error 1
but no accompanying diagnostic error message from gcc itself.
That lack of diagnostic error message concerns me because sometimes that
peculiar result can be a sign that there is an intermittent
hardware issue of some kind.
So to follow up, I suggest you cut and paste the exact /usr/bin/cc ... build
command from that
file for example 4 to see whether you can consistently reproduce the issue
by hand and to see if any other error message is revealed that was
somehow not captured by the comprehensive test script. And immediately
after running that /usr/bin/cc ... build command, you should test its
return code by
echo $?
If that result is non-zero, you know something was wrong with the
_immediately_ previous (in this case /usr/bin/cc ...) command even if there is
no
accompanying error message.
Also note you have (by design) two different copies of the x04c.c code.
There is the original source-tree (the working directory
of your git repository) location and
irwin@raven> grep 'x04c.c$' comprehensive_test_listing.out
-rw-r--r--+ 1 markus Domain Users 4131 May 23 2016
./shared/noninteractive/install_tree/share/plplot5.12.0/examples/c/x04c.c
You should double-check those two files are identical with each other
(in case the install location is afflicted with a disk error).
If you cannot replicate the non-zero return code by hand, then I
suggest you try running your launch script again to see if it again
consistently fails for example 4 for the CMake-based build system of
our installed examples. (And, of course, any lack of consistency from
one run to the next is likely due to a hardware issue unless your
launch script, Cygwin, or PLplot have changed between the two runs.)
II. The noninteractive comprehensive test for MinGW-w64/MSYS2
* Find issues:
DRIVERS_LIST: cairo;mem;ntk;null;pdf;ps;svg;wingcc;wxwidgets;xfig
ENABLE_ada: OFF
ENABLE_d: OFF
ENABLE_java: OFF
ENABLE_ocaml: OFF
ENABLE_octave: OFF
ENABLE_pdl: OFF
ENABLE_qt: OFF
ENABLE_pyqt4: OFF
ENABLE_pyqt5: OFF
ENABLE_itcl: OFF
ENABLE_itk: OFF
The only good historical comparison we have to these results is Greg's (see
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>).
where ada, d, java, ocaml, octave, pyqt4, itcl, and itk were
not present in the tests for various reasons. So the only real
regression above from those historical results was qt was disabled
(because it was not found). So the above is a quite encouraging result
but you are not quite there yet.
To resolve that last included component regression, what Qt-related
packages (if any) have you installed?
If the answer is none, I would preserve your current MinGW-w64/MSYS2
snapshot (since a new snapshot might not work at all), modify your
automated script to install that platform from scratch to include Qt
(Qt4 is preferred but if packaging conflicts insist you need to use
Qt5, then use that instead) and run that script to install a new
snapshot with its own unique install prefix.
Then repeat this test on that new snapshot platform with
DCMAKE_CXX_FLAGS=-fabi-version=8 adjusted to a new number if that is
needed).
* ERROR: Traditional make test_noninteractive failed in the installed
examples tree (for the nondynamic case)
A google search for the term <"gcc.exe: Bad address"> didn't appear
to find anything relevant. (There was one issue in Cygwin
for 2012 involving commands separated with a semicolon, but
we don't use a semicolon in the present case.)
As per usual when debugging such issues, you should cut and paste the
offending command from
nondynamic/noninteractive/output_tree/traditional_make_noninteractive.out
and make sure you can replicate the issue by hand. Then follow up by
systematically debugging that hand command. For example, it is
possible the command is too long so you might need to find another way
to, for example, read all those gcc options from a file.
Or one of those options might be in a form that is not acceptable
to the MinGW-w64/MSYS2 platform.
III. The interactive comprehensive test for MinGW-w64/MSYS2 that is
limited just to wxwidgets
All seems well here (indicating the uninitialized variable issue for
wxwidgets that is not yet fixed is not a major issue). So after your
holiday please follow up by running the identical test again except
for updated PLplot (to get my fix for the uninitialized variable which
should be ready by then) and adding the
-DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON cmake option. That option
means a lot more interactive work for you since you have to hit the
enter key to get through each page of each example that is displayed
and to exit each interactive example. But it also allows you to look
at each page of the various wxwidgets results to check there are no
gross rendering issues.
Also, please extend the present test by dropping the following script
options that you are currently using:
--do_nondynamic no
--do_static no
--do_test_install_tree no
--do_test_traditional_install_tree no
When these options default to yes, instead of just testing the shared
library/build-tree case you will be testing the 9 combinations of the
three shared, non-dynamic, and static cases with the three build_tree,
install_tree, and traditional_install_tree cases. That much wider
test coverage is quite worthwhile, but the amount of interactions you
will have to do to get through the test increases by a factor of 9 as
well.
Since I don't think rendering quality is going to be an issue for
these 9 different combinations, if the test of the above shared
library/build-tree case with -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON
demonstrates good rendering quality, I suggest you also drop the
-DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON option (which would then
default to OFF) for this 9-times-longer test to save yourself from
excessive hitting of the enter key. :-)
IV. Then follow up with the noninteractive MSVC comprehensive test
and the equivalent of the 3 interactive tests above, i.e.,
* shared library/build tree -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=OFF
(by default) to demonstrate there are no major wxwidgets issues.
* shared library/build tree -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON
to check if there are any major rendering issues with wxwidgets.
* All 9 combinations with -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=OFF
(by default) to demonstrate no major wxwidgets issues for any
of those combinations.
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
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
