On 2015-04-20 13:27-0700 Alan W. Irwin wrote: > On 2015-04-20 12:55-0700 Alan W. Irwin wrote: > >> Furthermore -debug works fine for me on MinGW/MSYS/Wine, but the only >> extra output from it comes after the device is selected from the list >> above. So to debug further you will have to (locally) add informative >> pldebug calls to the code near where the error message above >> "plInitDispatchTable: Could not open drivers directory, aborting >> operation" is being generated. >> >> I look forward to seeing those results from you. > > Hi Arjen: > > Actually, I take that "works fine for me" back. If you look at the > code, the error message is generated after a call to plGetDrvDir > which has pldebug() calls in it. Those work on Linux. > > Here is what happens on Linux when the the ps device has not been built > (to cut down on the debug output). > > software@raven> examples/c/x00c -debug -dev psc -o test.psc > plLoadDriver: Device not loaded! > plLoadDriver: tag=psc, drvidx=0 > plGetDrvDir: Using /home/software/plplot/HEAD/build_dir/drivers as the > driver directory. > plLoadDriver: Trying to load ps on > /home/software/plplot/HEAD/build_dir/drivers/ps > plLoadDriver: lt_dlopenext failed because of the following reason: > file not found > Unable to load driver: ps. > > *** PLPLOT ERROR, IMMEDIATE EXIT *** > Unable to load driver > Program aborted > > So there is a message from plGetDrvDir above on exactly what drivers > directory is being used in the build tree (which gets the build-tree > version of that directory because of the plInBuildTree() result). > > On MinGW/MSYS/Wine here is the equivalent result (again without the > ps.dll device available to make output short). > > bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc > plLoadDriver: Device not loaded! > plLoadDriver: tag=psc, drvidx=0 > plLoadDriver: Trying to load ps on ps > plLoadDriver: lt_dlopenext failed because of the following reason: > No error information > Unable to load driver: ps. > > *** PLPLOT ERROR, IMMEDIATE EXIT *** > Unable to load driver > Program aborted > > So in my particular MinGW/MSYS/Wine case I get this very strange > result that either (1) there is no call to plGetDrvDir at all or (2) > somehow pldebug is not working for just that particular routine. > > So I now find myself in the position of having to debug the -debug > option on this platform, and I hope you try that as well. > > And if you figure out that last sentence, it means you are truly a PLplot > guru. :-)
Hi Arjen: To follow up, the above difference is actually expected because plGetDrvDir is not called in that context on Windows platforms. However, that function is also called (both on Linux and Windows) in a different context (from plInitDispatchTable) where -debug was silent for all platforms. I have now corrected that silence (commit id c44f636). Here is the new -debug result on MinGW/MSYS/Wine (still without ps.dll built to shorten the messages). bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc 2>&1 |less plGetDrvDir: Using Z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/drivers as the driver directory. plInitDispatchTable: Scanning dyndrivers dir plInitDispatchTable: Consider file . plInitDispatchTable: Consider file .. plInitDispatchTable: Consider file ps.driver_info plInitDispatchTable: Opened driver info file ps.driver_info plInitDispatchTable: Consider file xfig.driver_info plInitDispatchTable: Opened driver info file xfig.driver_info plInitDispatchTable: Consider file pdf.driver_info plInitDispatchTable: Opened driver info file pdf.driver_info plInitDispatchTable: Consider file Makefile plInitDispatchTable: Consider file null.driver_info plInitDispatchTable: Opened driver info file null.driver_info plInitDispatchTable: Consider file CMakeFiles plInitDispatchTable: Consider file mem.driver_info plInitDispatchTable: Opened driver info file mem.driver_info plInitDispatchTable: Consider file svg.driver_info plInitDispatchTable: Opened driver info file svg.driver_info plInitDispatchTable: Consider file wingcc.driver_info plInitDispatchTable: Opened driver info file wingcc.driver_info plInitDispatchTable: Consider file ntk.driver_info plInitDispatchTable: Opened driver info file ntk.driver_info plInitDispatchTable: Consider file cmake_install.cmake plInitDispatchTable: Consider file CTestTestfile.cmake plLoadDriver: Device not loaded! plLoadDriver: tag=psc, drvidx=0 plLoadDriver: Trying to load ps on ps plLoadDriver: lt_dlopenext failed because of the following reason: No error information Unable to load driver: ps. *** PLPLOT ERROR, IMMEDIATE EXIT *** Unable to load driver Program aborted So obviously in this case the drivers directory is being found properly by plGetDrvDir called from plInitDispatchTable. If you look at the plGetDrvDir code in src/plcore.c, the only case where PLPLOT_DRV_DIR is important is if the build-tree detection fails. So basically the difference between us is plInBuildTree() == 1 for my platform but not for yours which you can confirm by doing the above individual test and looking at the form of the first message that comes out (which is different if plInBuildTree() == 1 is not detected). And if the build-tree detection is failing for you that screws up lots of other build-tree stuff, and jibes with you having to brute-force the problem by setting other PLPLOT-related environment variables as well. It turns out the plInBuildTree logic depends closely on whether the directory separator is a "/" or a "\", and I suspect what has happened is my older version of MSYS uses "\" while your more modern version uses "/" in this context. Accordingly, I have changed the plInBuildTree code to work for either separator on Windows (commit ID 8ffab0b). That change gave the same good results as above for me, and I hope it will also solve _all_ your brute force issues (i.e., reliance on PLPLOT* environment variables can be dropped) on your more modern MinGW/MSYS. If that change works for you with individual tests, then please follow up with the corresponding comprehensive test with no PLPLOT-* environment variables set. And if that is a success please repeat with --do_clean_as_you_go no dropped (since there is no need to chew up your disk space anymore) and you also should drop --do_ctest no --do_test_interactive no to make the test as strong as possible (outside using the epa_build variation of this test which strengthens it even more by building some of the soft dependencies for PLplot such as pkg-config, Tcl/Tk, qhull, and shapelib). If you have any failures along the way, the usual corresponding tarball is requested. But if every test is a success, then you are done with MinGW/MSYS testing (YEAH!), and I only need that tarball for the last (strongest) test so I can post those good results on our wiki as a benchmark to help guard against future regressions introduced in this release cycle. I hope you find these new developments as interesting as I do. I have been frustrated for years by PLplot just not working very well on the various Windows platforms, and it feels really good to be able to tackle some of these issues now thanks to your willingness to run comprehensive tests on various Windows platform and the vastly improved automatic data collection for your comprehensive test results that now exists. 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 __________________________ ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
