Menu
▾
▴
Re: [Plplot-devel] Planning for the release of 5.13.0
|
From: Alan W. I. <ir...@be...> - 2017-07-18 23:43:11
|
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 __________________________ |
