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

Reply via email to