Hi Arjen:
Thanks for those test results. More below.
On 2014-05-23 14:18-0000 Arjen Markus wrote:
> Hi Alan,
>
> Here is the output from the command "./x00c -dev psc -debug -o test.ps" (well
> the first part, related to the various files), built on Cygwin 64 bits:
>
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=psc, drvidx=3
> plLoadDriver: Trying to load ps on ps
> plGetName: Maximum length of full pathname of file to be found is 59
> plGetName: Full pathname of file to be found is
> /cygdrive/d/plplot-svn/plplot/data/cmap0_default.pal
> plLibOpenPdfstr: Found file
> /cygdrive/d/plplot-svn/plplot/data/cmap0_default.pal
> plGetName: Maximum length of full pathname of file to be found is 59
> plGetName: Full pathname of file to be found is
> /cygdrive/d/plplot-svn/plplot/data/cmap0_default.pal
> plLibOpenPdfstr: Found file
> /cygdrive/d/plplot-svn/plplot/data/cmap0_default.pal
> plGetName: Maximum length of full pathname of file to be found is 59
> plGetName: Full pathname of file to be found is
> /cygdrive/d/plplot-svn/plplot/data/cmap1_default.pal
> plLibOpenPdfstr: Found file
> /cygdrive/d/plplot-svn/plplot/data/cmap1_default.pal
> plOpenFile: Opened test.ps
> plGetName: Maximum length of full pathname of file to be found is 53
> plGetName: Full pathname of file to be found is
> /cygdrive/d/plplot-svn/plplot/data/plxtnd5.fnt
> plLibOpenPdfstr: Found file /cygdrive/d/plplot-svn/plplot/data/plxtnd5.fnt
> set_font: fci = 0x80000000, font name = Helvetica
> proc_str: unicode = 0x30, type 1 code = 48
> proc_str: unicode = 0x2e, type 1 code = 46
> proc_str: unicode = 0x30, type 1 code = 48
> ... (skipping a lot of similar output)
>
> The drivers themselves are coming from the installation directory
> /usr/local/lib/plplot5.10.0/drivers, but the .pal and .fnt files are coming
> from the build directory. I have not set any specific environment variables,
> other than the path.
>
> The size_t issue is definitely solved, but I am not sure it should find the
> data files in the build directory. Oh, I move the program out of the build
> directory and now it comes up with the paths from the installation indeed. So
> I guess that is covered too.
Those results (for both the build tree and install tree case) sound
fine for the data files and the maximum string lengths are obviously
reasonable numbers so it appears my code changes are working well for
you on Cygwin.
There is still one issue, however, in the results you report. You
state for the build-tree case that the drivers are being loaded from
the install tree. Are you sure? Because there is nothing in the
above messages that confirms or denies that and that result is
obviously not the desired one (where the build-tree version of the
drivers should be used for the build-tree case).
The logic for whether drivers are found in build tree or install tree
is a bit tricky to figure out on Cygwin, but it can be done: The above line
> plLoadDriver: Trying to load ps on ps
means (as expected from the Cygwin-specific code in plLoadDriver) that
there is no directory prepended to drvspec (as there would be on Linux). So
the code
driver->dlhand = lt_dlopenext( drvspec );
is searching for "ps" without any pathname. It also turns out (which
was a surprise to me) that on Cygwin LTDL_WIN32 is not ON (see
Cygwin-specific logic in cmake/modules/drivers.cmake) so
src/ltdl_win32.c is not included in libplplot, i.e., the Cygwin system
version of lt_dlopenext is used. For that case lt_dlopenext("ps")
obviously works for you, but it appears you have to rely on
documentation of lt_dlopenext to discover from what location that "ps"
is being loaded.
The GNU documenation of lt_dlopenext (i.e.,
<http://www.gnu.org/software/libtool/manual/html_node/Libltdl-interface.html>)
says the following about where searches for dll filenames like "ps"
without a directory component are done:
<quote>
If libltdl cannot find the library and the file name filename does not
have a directory component it will additionally look in the following
search paths for the module (in the following order):
1. user-defined search path: This search path can be changed by the program
using the functions lt_dlsetsearchpath, lt_dladdsearchdir and
lt_dlinsertsearchdir.
2. libltdl's search path: This search path is the value of the environment
variable LTDL_LIBRARY_PATH.
3. system library search path: The system dependent library search path (e.g.
on GNU/Linux it is LD_LIBRARY_PATH).
</quote>
As far as I know, we do not use 1., and I also presume you are not
setting LTDL_LIBRARY_PATH or LD_LIBRARY_PATH. But if we trust that
documentation for the Cygwin case, then "the system dependent library
search path" should be the PATH environment variable.
Thus, I am wondering if your result of incorrectly loading the
install-tree ps device driver for the build-tree case is simply
because your PATH wasn't set properly?
If your PATH is set correctly for the build-tree case (i.e., it
includes the dll subdirectory of the build tree where the build-tree
version of the drivers are located but does _not_ include any
install-tree component), then I am virtually positive from the above
documentation that the build-tree ps device will be loaded as desired.
And if your PATH is set correctly for the install-tree case (i.e., it
excludes all components from the build tree and puts the install-tree
drivers subdirectory on the PATH), then I am virtually positive from
the above documentation that the install-tree ps device will be loaded
as desired.
Do you agree with this interpretation of the GNU documentation for
lt_dlopenext, and do you have some way to confirm (e.g., by
removing/renaming the install-tree or build-tree ps device driver as
well as changing the PATH you have set) that conclusion that on Cygwin
it is the PATH that is actually controlling whether the build-tree or
install-tree version of the devices is being loaded?
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
__________________________
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
