plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Alan W. I. <ir...@be...>]

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.  :-)

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
__________________________

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Alan W. I. <ir...@be...>]

On 2015-04-20 14:57-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> Then attempt to run the built example once with PLPLOT_DRV_DIR set to above
>> and once with PLPLOT_DRV_DIR set to nothing (PLPLOT_DRV_DIR=).
>>
>> examples/c/x00c -debug -dev psc -o test.psc 2>&1 |\ grep -v unicode |grep -v
>> set_font
>>
> I get some, let's say, interesting results:
>
> ./x00c -debug
>
> does not give any additional output (I only expanded the PATH to get the program to work). The screen output:
>
> $ ./x00c -debug
>
>
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
>
> plInitDispatchTable: Could not open drivers directory, aborting operation
>
>
>
> Plotting Options:
>
>
>
> Enter device number or keyword:
>
>
>
> Invalid device:
>
>
>
> Plotting Options:
>
>
>
> Enter device number or keyword:
>
> Invalid device:
>
>
>
> I do not have time to check the definition of pldebug() right now. Maybe it is a no-op?

I get nothing like the above empty results on MinGW/MSYS.  For example
(with just the dll on the PATH with printenv showing nothing with
a PLPLOT prefix being set)

bash.exe-3.1$ examples/c/x00c

Plotting Options:
  < 1> wingcc     Win32 (GCC)
  < 2> ps         PostScript File (monochrome)
  < 3> psc        PostScript File (color)
  < 4> xfig       Fig file
  < 5> null       Null device
  < 6> ntk        New tk driver
  < 7> mem        User-supplied memory device
  < 8> svg        Scalable Vector Graphics (SVG 1.1)
  < 9> pdf        Portable Document Format PDF

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.

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
__________________________

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Then attempt to run the built example once with PLPLOT_DRV_DIR set to above
> and once with PLPLOT_DRV_DIR set to nothing (PLPLOT_DRV_DIR=).
>
> examples/c/x00c -debug -dev psc -o test.psc 2>&1 |\ grep -v unicode |grep -v
> set_font
>
I get some, let's say, interesting results:

./x00c -debug

does not give any additional output (I only expanded the PATH to get the program to work). The screen output:

$ ./x00c -debug



*** PLPLOT ERROR, ABORTING OPERATION ***

plInitDispatchTable: Could not open drivers directory, aborting operation



Plotting Options:



Enter device number or keyword:



Invalid device:



Plotting Options:



Enter device number or keyword:

Invalid device:



I do not have time to check the definition of pldebug() right now. Maybe it is a no-op?

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Alan W. I. <ir...@be...>]

Hi Arjen:

On 2015-04-20 11:31-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>

> I added the option "-do_clean_as_you_go no" to the test script. The
result is attached. Hopefully this will shed some light on the
anomalies MinGW/MSYS is causing.

My updated script appears not to be capturing the script itself for
some reason.  I cannot spot any typographical errors with how
SCRIPTNAME is being used within the script. By any chance, have you
renamed the script without updating SCRIPTNAME to be consistent?
Anyhow, please fix whatever the problem is since the captured script
within the tarball is useful since it has tailored sections which are
useful to know for each run.

As far as the results are concerned, please look at env.out, you can
see that

PLPLOT_DRV_DIR=/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/drivers

is set there, and I presume that was not subsequently modified by the
script.

However, from the list of files all the dll's are properly collected in
the dll directory:

/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/dll

rather than the drivers directory.  Furthermore
if you look at what is actually in the drivers directory
pointed to by PLPLOT_DRV_DIR, you find a bunch of CMake and Make
files and also *.driver_info files.

At first I was going to dismiss those *.driver_info files as output only, but now I see
in src/plcore.c there is an attempt to read them.  That process
works without PLPLOT_DRV_DIR set on my MinGW/MSYS/Wine platform
by that is required on your platform for some reason.  Typically
such PLplot file reads use several alternative methods so I
presume one of those is working here, but not there so you
have to fall back to PLPLOT_DRV_DIR.

To make further progress could you please take a look at src/plcore.c
to trace through how PLPLOT_DRV_DIR is used there for the
*.driver_info files?  I will do that as well here (somewhat later
today after I have had some sleep).

To help with that task, also run the x00 example by hand
using the -debug option.  Please mimic the script by putting the dll subdirectory
on your PATH, execute

cd \
/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree,

and make sure the example and device
driver are built using

make  x00c; make ps

Then attempt to run the built example once with PLPLOT_DRV_DIR set to above and once
with PLPLOT_DRV_DIR set to nothing (PLPLOT_DRV_DIR=).

examples/c/x00c -debug -dev psc -o test.psc 2>&1 |\
grep -v unicode |grep -v set_font

(The grep stanzas remove lots of debug noise consisting of glyph details.)

Here is the corresponding result here on MinGW/MSYS/Wine
# Show PLPLOT_DRV_DIR not set
bash.exe-3.1$ printenv |grep PLPLOT
bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc 2>&1 | grep -v unicode |grep -v set_font 
plLoadDriver: Device not loaded!
plLoadDriver: tag=psc, drvidx=0
plLoadDriver: Trying to load ps on ps
plGetName: Maximum length of full pathname of file to be found is 115
plGetName: Full pathname of file to be found is z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\c
map0_default.pal
plLibOpenPdfstr: Found file z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\cmap0_default.pal
plGetName: Maximum length of full pathname of file to be found is 115
plGetName: Full pathname of file to be found is z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\c
map0_default.pal
plLibOpenPdfstr: Found file z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\cmap0_default.pal
plGetName: Maximum length of full pathname of file to be found is 115
plGetName: Full pathname of file to be found is z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\c
map1_default.pal
plLibOpenPdfstr: Found file z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\cmap1_default.pal
plOpenFile: Opened test.psc
plGetName: Maximum length of full pathname of file to be found is 109
plGetName: Full pathname of file to be found is z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\p
lxtnd5.fnt
plLibOpenPdfstr: Found file z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/build_plplot_lite\data\plxtnd5.fnt

For completeness, I also ran the same example with PLPLOT_DRV_DIR set to the drivers
directory, e.g.,

bash.exe-3.1$ export PLPLOT_DRV_DIR=$(pwd)/drivers
bash.exe-3.1$ printenv |grep PLPLOT
PLPLOT_DRV_DIR=/z/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/drivers

but (as expected) got the exact same results.

In sum, to figure out this platform difference it is time for both of
us to start using the -debug option and dig through the code to
throughly understand how the *.driver_info files are accessed and used
with or without PLPLOT_DRV_DIR set.

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
__________________________

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



I added the option "-do_clean_as_you_go no" to the test script. The result is attached. Hopefully this will shed some light on the anomalies MinGW/MSYS is causing.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> To help figure this out if 1 is absolutely needed in your case, then I need you to run
> the script again as before (with 1, 2, and 3 set and with your present script options
> set) with the following additional script options:
>
> --do_clean_as_you_go no
>


DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-20 06:45-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> That is good news indeed.  So it appears we finally have a good baseline result for
>> Cygwin without any brute force changes.
>> I am well aware you have been contributing a lot of your time to achieve these
>> improved and extremely valuable comprehensive testing results not only for Cygwin
>> but also MinGW/MSYS so thanks very much for this effort!
>>
>> So since you have been working so hard at this, I want to emphasize any further
>> requests are very much for "whenever your time constraints permit".
>>

> I will see what I can do - with the current automation of the
automated tests it is merely a matter of preparing and starting the
next batch and wait for it to complete. That is less time consuming
than figuring out why things did not work at all :). Still, it does
require some attention, especially the preparation part. Thanks for
the updated script, BTW.

You are welcome.  When you tailor that updated script (which automatically
collects a list of the names and attributes of every file generated) with the
--do_clean_as_you_go no option, I think that should finally give me
enough information to help you with the figuring out part :-)

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
__________________________

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> That is a pretty cool automated script for running the test and collecting all relevant
> results into a tarball.  The only thing I would add to it is
>
> rm -rf ../comprehensive_test_disposeable
>
> right at the start so there are no stale results left in that directory from previous runs
> of the script.
>

Yes, that is indeed missing. I now do this manually.

> By looking at env.out, and also your script I find you have set 1.
> PLPLOT_DRV_DIR=/d/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree/drivers
> 2. PLPLOT_LIB=/d/plplot-svn/plplot-git/data
> 3. PL_LIBRARY=/d/plplot-svn/plplot-git/bindings/tk
>
> None of those should be necessary, and mean that when you are purportedly testing
> the installed examples tree, you are actually (1) using drivers from the (shared only)
> build tree, (2) data from the source tree, and (3) Tk results from the source tree(?).
> That is, all of these are brute-force workarounds for MinGW/MSYS that I don't need
> to use here and which we should figure out how to avoid in your case.
>
> So you have actually changed 3 things between the test that succeeds and the one
> that does not.
>
> Let's deal with 2 and 3 later, but
> if you leave 2 and 3 in place, do you really need 1?
>
These things are also necessary when running the examples manually under MinGW/MSYS. Somehow the "built-in-tree" logic is not working for this platform. Leaving out no. 1 makes the test script hang on x00c asking for a driver. I verified this by running it via a reduced script (setting 2, 3 and directly running x00c).

My laptop has a fairly large disk, so leaving the files should not be too much of a problem. Luckily. I will keep you informed about the progress.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> That is good news indeed.  So it appears we finally have a good baseline result for
> Cygwin without any brute force changes.
> I am well aware you have been contributing a lot of your time to achieve these
> improved and extremely valuable comprehensive testing results not only for Cygwin
> but also MinGW/MSYS so thanks very much for this effort!
>
> So since you have been working so hard at this, I want to emphasize any further
> requests are very much for "whenever your time constraints permit".
>
I will see what I can do - with the current automation of the automated tests it is merely a matter of preparing and starting the next batch and wait for it to complete. That is less time consuming than figuring out why things did not work at all :). Still, it does require some attention, especially the preparation part. Thanks for the updated script, BTW.

When I have new results, I will report them in the same way as before.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-19 14:15-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> When rewriting this PATH manipulation logic after the 5.11.0 release I screwed up
>> one aspect (forgot the nondynamic case), and your test found that script bug.  Sorry
>> about that!  Please try again (for commit id c689ff3 which fixes this issue).
>>
>> Regardless of success or failure, full report please.
>>

> Yes, that change did the trick - the (restricted) completed without a problem. See the attached tarball.

That is good news indeed.  So it appears we finally have a good
baseline result for Cygwin without any brute force changes.
I am well aware you have been contributing a lot of your time to
achieve these improved and extremely valuable comprehensive testing
results not only for Cygwin but also MinGW/MSYS so thanks very
much for this effort!

So since you have been working so hard at this, I want to emphasize
any further requests are very much for "whenever your time constraints
permit".

But if you do have more time to continue now please run this test again
with less narrow restrictions.

That is, remove the current

--do_ctest no
--do_test_traditional_install_tree no
--do_test_interactive no

options until you run into an issue.  I think ctest worked fine for
you before so that should not be an issue.  Furthermore, my latest
traditional build fix for Ubuntu, might also have solved the
do_test_traditional_install_tree issues you were running into before.
And if that works, then that just leaves the interactive issue you
discovered which was (I believe) X was not connecting properly.
Anyhow, I hope you can figure that out since I believe you did get
the xwin device to work (but quite slowly) in previous Cygwin tests.
But if you cannot figure out the X problem, perhaps we should add a
build-system option to disable X so you can use that and
also allow interactive tests of, e.g., the wingcc and ntk devices
which are not X based?

Once removing the above restrictions works (or can be narrowed down
to disabling X11 on Cygwin) (and again if your current time
constraints permit) you should
also look carefully at the WARNING messages in
shared/output_tree/cmake.out to see why so many components
of PLplot are being dropped.  The most important of these
WARNING messages are as follows:

-- WARNING: swig not found. Disabling java bindings
-- WARNING: swig not found. Disabling Python bindings
-- WARNING: swig not found. Disabling Octave bindings
-- WARNING: Disabling Itcl interface code
-- WARNING: setting ENABLE_tk to OFF
-- WARNING: no working Ada compiler so disabling Ada bindings and examples.
-- WARNING: swig not found. Disabling Lua bindings
-- WARNING: no working D compiler so disabling D bindings and examples.
-- WARNING: qhull library not found.  Setting PL_HAVE_QHULL to OFF.
-- WARNING: pango, pangoft2, or lasi not found with pkg-config.
-- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to OFF.
-- WARNING: Setting PLD_pdf to OFF.
-- WARNING:ocamlc not found. Disabling ocaml bindings

You will have to check the context of these warning messages for why
certain Tcl/Tk/Itcl/Itk components were disabled.  For example, Tk was
dropped because of a Tk version inconsistency discovered by the PLplot
build system so to enable Tk again you will have to figure out why
that inconsistency is occurring.

With regard to the non Tcl/Tk/Itcl/Itk warnings, I have just checked
the python x86_64 packages at
<http://cygwin.com/cgi-bin2/package-grep.cgi> which allows a very nice
regular expression search of package names and files within the
packages.  I urge you to try such searches for yourself.

My search for "gdc" (the D compiler) and "haru" and "hpdf" (possible
names for the library prerequisite for the pdf device driver) did not
turn up anything relevant.  So

-- WARNING: no working D compiler so disabling D bindings and examples.
-- WARNING: Setting PLD_pdf to OFF.

are likely a lost cause on Cygwin.

However, my searches for the terms swig, (and java, python, octave, and
lua, if they are not installed already on your Cygwin platform),
qhull, ada, lasi, wx, and ocamlc all found something relevant so with
some care in selecting the packages to install most of the above
warnings should go away and, for example, the following list of
current disabled bindings

ENABLE_ada:             OFF
ENABLE_java:            OFF
ENABLE_lua:             OFF
ENABLE_ocaml:           OFF
ENABLE_octave:          OFF
ENABLE_python:          OFF
ENABLE_pyqt4:           OFF
ENABLE_itcl:            OFF
ENABLE_tk:              OFF
ENABLE_itk:             OFF
ENABLE_wxwidgets:       OFF

should all be ON and part of the (much broader) comprehensive test
unless you must explicitly disable these components because they don't
work for some reason, and, of course, finding out which components
currently don't work is the whole point of these tests.

Once all relevant Cygwin packages are installed and the script (with
PLplot components which you have dropped) completes with no issues,
then (again as time permits) we can start jointly working on the build
system bugs for Cygwin your dropped components reveal so that these
dropped components can be reinstated again one by one without messing
up the comprehensive test.

In sum, you have made an excellent start with Cygwin, but as time
permits I hope you deal with these remaining issues with the final
goal of having a comprehensive test success with all possible
components of PLplot enabled which would make PLplot on Cygwin
essentially just as powerful as it is on Linux.

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
__________________________

Re: [Plplot-devel] Comprehensive testing: IMPORTANT: improved collection by script

[Alan W. I. <ir...@be...>]

On 2015-04-19 15:32-0700 Alan W. Irwin wrote:

> On 2015-04-19 15:08-0000 Arjen Markus wrote:
>
>> [.... B]y running the example as built in the
> comprehensive_test_disposeable directory, I found what was wrong: my
> script did not set the PLPLOT_DRV_DIR environment variable, so that
> the example could not detect which drivers were available. After
> correcting that (I must have set it in the shell before, rather than
> via the script), the example worked and now the script is happily
> running.
>
> Hi Arjen:
>
> That is a pretty cool automated script for running the test and
> collecting all relevant results into a tarball.  The only
> thing I would add to it is
>
> rm -rf ../comprehensive_test_disposeable
>
> right at the start so there are no stale results left in that directory
> from previous runs of the script.

This e-mail is important to consider before doing any more tests.  I
just realized additional changes should be made to your script beyond
the above.  For example, your script lists only a subset of the files that are
generated by the comprehensive_test.sh script, and your script is also missing some key
things to collect (the script itself and the environment variables).
You included those results by hand for the MinGW/MSYS case, but forgot
to do that for the corresponding Cygwin case.

I have accordingly made some changes to the script as well as some style
changes to make the script easier to tailor (see attached).
Note, these changes are untested, but well documented so you should
get the idea of what I would like to see done if something doesn't
work.  Also, I double-checked that the line endings are right for
you (emacs recognized this as a Windows file and kept the line endings
you started with).

Once you verify this new script result works for the MinGW/MSYS case,
it should require only a small amount of tailoring to make this script
also do everything you need for the Cygwin case.

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
__________________________

Re: [Plplot-devel] wxwidgets error when building plplot 5.11.0 on FreeBSD

[Ben W. <woo...@gm...>]

Thanks for the feedback Alan.

I have removed the -DPLD_wxpng:BOOL=ON option and it is all working well
now. Thanks!

Regards,
Ben
On Fri, 17 Apr 2015 at 9:23 am Alan W. Irwin <ir...@be...>
wrote:

> On 2015-04-16 22:48-0000 Ben Woods wrote:
>
> > Hey everyone,
> >
> > I'm trying to build plplot 5.11.0 on FreeBSD with wxwidgets support. I
> > have wx28-gtk2-2.8.12 and agg-2.5_11 installed, and am compiling with
> > the following options:
> > -DPLD_wxpng:BOOL=ON
> > -DwxWidgets_CONFIG_EXECUTABLE:FILEPATH="/usr/local/bin/wxgtk2-2.8-config"
>
>
> > -- WARNING: You have enabled the PLD_wxpng device which is disabled by
> > default either because it is deprecated or because there are know
> > issues with it. Please check the documentation / release notes for
> > details.
>
> Hi Ben:
>
> I have reviewed our old mailing list archive and
> PLD_wxpng has been disabled by default since its implementation many
> years ago because it had all sorts of run-time problems (segfaults, etc.),
> and nobody has fixed it since.
>
> Just out of curiosity I tried to use
>
> -DPLD_wxpng:BOOL=ON
>
> as you did above,
>
> and I got the following build error (which apparently is not the same as
> your
> build error):
>
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In function
> ‘void plD_init_wxpng(PLStream*)’:
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:231:5: error:
> ‘wxPLDevBase’ was not declared in this scope
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:231:18: error:
> ‘dev’ was not declared in this scope
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:232:28: error:
> ‘common_init’ was not declared in this scope
> make[3]: *** [drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.o] Error 1
> make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/all] Error 2
> make[1]: *** [drivers/CMakeFiles/wxwidgets.dir/rule] Error 2
> make: *** [wxwidgets] Error 2
>
> So it appears wxpng has fallen into even a greater state of
> disrepair (it now doesn't even build) for the new wxwidgets implementation
> used for 5.11.0.  It might build (but would probably still have the
> same run-time errors as previously) if you used the -DOLD_WXWIDGETS=ON
> option we have implemented for 5.11.0 to give access to the old
> wxwidgets implementation.
>
> But I think what you really should do is pay attention to the above
> warning message and do not use the -DPLD_wxpng:BOOL=ON option for
> 5.11.0 at all.
>
> @Phil:
>
> I think Werner's historical idea with wxpng was as a proof-of-concept
> that wxwidgets could be the basis of a whole bunch of additional file
> device drivers.  He obviously never got that idea to work properly,
> but it might be a lot easier now with modern wxwidgets and your
> simplification/rationalization of our own wxwidgets-related code.
>
> Anyhow, my advice is to consider this possibility.  If you think wxpng
> (and other possible file devices) are a good idea and straightforward
> to implement properly with you new wxwidgets approach, then please put
> getting wxpng to build and actually execute properly without segfaults
> on your wxwidgets ToDo list.  Otherwise, though, you should remove the
> wxpng code from your new wxwidgets source files so nobody runs into
> the type of build errors I did above for new wxwidgets.
>
> 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
> __________________________
>

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Alan W. I. <ir...@be...>]

On 2015-04-19 15:08-0000 Arjen Markus wrote:

> [.... B]y running the example as built in the
comprehensive_test_disposeable directory, I found what was wrong: my
script did not set the PLPLOT_DRV_DIR environment variable, so that
the example could not detect which drivers were available. After
correcting that (I must have set it in the shell before, rather than
via the script), the example worked and now the script is happily
running.

Hi Arjen:

That is a pretty cool automated script for running the test and
collecting all relevant results into a tarball.  The only
thing I would add to it is

rm -rf ../comprehensive_test_disposeable

right at the start so there are no stale results left in that directory
from previous runs of the script.

By looking at env.out, and also your script I find you have set
1. PLPLOT_DRV_DIR=/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/drivers
2. PLPLOT_LIB=/d/plplot-svn/plplot-git/data
3. PL_LIBRARY=/d/plplot-svn/plplot-git/bindings/tk

None of those should be necessary, and mean that when
you are purportedly testing the installed examples tree, you are
actually (1) using drivers from the (shared only) build tree, (2) data from the
source tree, and (3) Tk results from the source tree(?). That is, all of
these are brute-force workarounds for MinGW/MSYS that I don't need
to use here and which we should figure out how to avoid in your case.

So you have actually changed 3 things between the test that succeeds and
the one that does not.

Let's deal with 2 and 3 later, but
if you leave 2 and 3 in place, do you really need 1?

The reason I ask is your script output clearly documents

Prepend
/d/plplot-svn/plplot-git/../comprehensive_test_disposeable/shared/build_tree/dll
to the original PATH

occurs before anything happens in the build tree for the shared case

and

Prepend
/d/plplot-svn/plplot-git/../comprehensive_test_disposeable/shared/install_tree/bin
to the original PATH
Prepend
/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib/plplot5.11.0/drivers
to the current PATH

occurs before anything happens in the installed examples build tree for the
shared case.

So as long as those directories are properly populated with the dll
part of shared libraries and the device driver dll's, then all should be
well and you should not need 1 at all.

To help figure this out if 1 is absolutely needed in your case, then
I need you to run the script again
as before (with 1, 2, and 3 set and with your present script
options set) with the following additional script options:

--do_clean_as_you_go no

This option means the script does not clean up the interesting
results.  Therefore, with this option the
file lists that you include in your tarball reflects what is there
in /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/drivers
and also
/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/dll
(the directory put on the PATH by the script) when the test is being
executed without any subsequent cleanup to remove the interesting stuff.

However, the above option does have the potential to consume a lot of disk space (something
roughly like 50GB for a complete comprehensive test on fully loaded
Linux systems, but presumably a lot less than that on MinGW/MSYS
system missing many PLplot soft dependencies).  Thus, if you are short
of spare disk space, you _could_
temporarily narrow the tests as much as possible by, e.g.,
dropping all but the shared case

--do_nondynamic no
--do_static no

Also, you could narrow the tests even further by limiting all results to just C tests for just the ps devices by specifying

--cmake_added_options "-DDEFAULT_NO_BINDINGS=ON -DDEFAULT_DEFAULT_NO_DEVICES=ON -DPLD_psc=ON -DPLD_ps=ON"

But whether or not you set these last three options is up to you
depending on any concerns you might have concerning disk space.

In sum, I think we are making good progress on MinGW/MSYS with only 3
brute force workarounds left to deal with on your MinGW/MSYS platform
that are not required on mine.  But some more experiments with running
the script (with a complete automated tarball report for each case)
should soon sort out what the issues are on your MinGW/MSYS platform.

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
__________________________

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



Here is the result.



Regards,



Arjen




From: Arjen Markus [mailto:Arj...@de...]
Sent:

Alas, no pop-up. But by running the example as built in the comprehensive_test_disposeable directory,  I found what was wrong: my script did not set the PLPLOT_DRV_DIR environment variable, so that the example could not detect which drivers were available. After correcting that (I must have set it in the shell before, rather than via the script), the example worked and now the script is happily running.

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Your actual script output is
> [...]
> This variable specifies whether any windows platform has been detected
> ANY_WINDOWS_PLATFORM=true
>
> Each of the steps in this comprehensive test may take a while....
> Prepend
> /d/plplot-svn/plplot-git/../comprehensive_test_disposeable/shared/build_tree/dll
> to the original PATH
> cmake in the build tree
> make VERBOSE=1 test_noninteractive in the build tree
> ERROR: make test_noninteractive failed in the build tree
>
> So the windows detection is working and so is the PATH manipulation to put the dll
> subdirectory on the PATH.  The script does exit with the above error message rather
> than just silently hanging.
> So this seems like an ordinary error to me rather than a hang, but I must admit that
> does not explain why x00c.exe continues to run after it generated the error below.
>

No, the script hangs and when I kill off x00c.exe, then it is able to continue and write out the error messages. I should have been clearer about this behaviour.

>
> If you look further at shared/output_tree/make_noninteractive.out
> you have:
> [...]
> Generate C results for xfig file device
> cd /D/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples &&
> env EXAMPLES_DIR=D:/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree/examples
> SRC_EXAMPLES_DIR=d:/plplot-svn/plplot-git/examples OUTPUT_DIR=D:/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree/examples/test_examples_o
> utput_dir c:/MinGW/msys/1.0/bin/bash.exe D:/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree/plplot_test/plplot-test.sh --
> verbose --front-end=c --device=xfig Testing front-end c x00c
> make[3]: *** [examples/test_examples_output_dir/x01c01.xfig] Error 1
> make[3]: Leaving directory `/d/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree'
> make[2]: *** [examples/CMakeFiles/test_c_xfig.dir/all] Error 2
> make[2]: Leaving directory `/d/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree'
> make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
> make[1]: Leaving directory `/d/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree'
> make: *** [test_noninteractive] Error 2
>
> So it appears that example is failing for unknown reasons (Error 1), and there is no
> mention of not being able to find a dll.  Was there some popup concerning this error
> that gave more information about it?
>

Alas, no pop-up. But by running the example as built in the comprehensive_test_disposeable directory,  I found what was wrong: my script did not set the PLPLOT_DRV_DIR environment variable, so that the example could not detect which drivers were available. After correcting that (I must have set it in the shell before, rather than via the script), the example worked and now the script is happily running.

> In sum, it seems to me the script is doing its job with regard to Windows detection
> and PATH manipulation, and I have no idea why the above run-time error occurred
> for the first attempt to run any example.  So I am completely puzzled by these results.
>
See the above.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> When rewriting this PATH manipulation logic after the 5.11.0 release I screwed up
> one aspect (forgot the nondynamic case), and your test found that script bug.  Sorry
> about that!  Please try again (for commit id c689ff3 which fixes this issue).
>
> Regardless of success or failure, full report please.
>
Yes, that change did the trick - the (restricted) completed without a problem. See the attached tarball.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive Testing: Ubuntu 14:10

[Andrew R. <and...@us...>]

On Sun, Apr 19, 2015 at 09:56:47AM +0100, Andrew Ross wrote:
> 
> I didn't want to comment on your code, but that was the impression I got!
> I am using g++-4.9, but I did the g++ --verbose --version test on Ubuntu
> versions back to 4.4 and all used the colon. I agree, dropping it is
> perhaps the best. Presumably the linkage with the CXX compiler should only
> be if the C++ bindings are enabled? This is almost always going to be the
> case these days, but someone might want to compile a minimal C only
> static library for embedded purposes?

OK. Looking at your commit, you've already dealt with corner case I see.

Andrew

Re: [Plplot-devel] Comprehensive Testing: Ubuntu 14:10

[Andrew R. <and...@us...>]

On Sat, Apr 18, 2015 at 05:00:52PM -0700, Alan Irwin wrote:
> On 2015-04-18 22:56+0100 Andrew Ross wrote:
> 
> >
> >Alan,
> >
> >I've finally got time to rerun my comnprehensive tests with Ubuntu 14.10
> >and try to debug the niggle issues I encountered with the static build
> >
> >(My only change from last time is that I've had to build cmake from source
> >to get a new enough version - I'm using 3.2.2)
> [...]
> >2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
> >me. The comments suggest that g++ returns a semicolon delimited list of
> >paths, which is just like a cmake list so no manipulation is needed. At
> >least on my system it is actually colon separated. Replacing the colons
> >with semicolons fixes the problem and ensures the correct linkage options
> >for pkg-config, and hence the traditional examples build. I've not
> >commited this fix, since it might upset other people. In particularly on
> >windows the colon may be used for drive letters? Can others check
> >what g++ returns to check that a simple replacement of colons with
> >semicolons wouldn't break anything? Try g++ --verbose --version and look
> >at what LIBRARY_PATH is set to.
> 
> The problem is that libplplot is a mixed C and C++ library for the
> nondynamic or static case (because of including C++ drivers code in
> the library for those cases).  Therefore, for the traditional build
> system for the installed examples, when gcc is used to link a C
> example a specific link to libstdc++.so has to be provided.
> 
> The code in src/CMakeLists.txt to find that library is really ugly,
> works only for g++ and no other C++ compiler, and depends on g++
> internals which apparently have now changed.  And colon separation
> when there are drive letters is a real pain to deal with.  So I plan
> to abandon that code completely and simply solve the problem
> in a general way for the static and nondyamic cases by using the CXX
> compiler (which automatically links in libstdc++.so) for building
> the C examples using the traditional build system. Implementation
> to follow....

I didn't want to comment on your code, but that was the impression I got!
I am using g++-4.9, but I did the g++ --verbose --version test on Ubuntu
versions back to 4.4 and all used the colon. I agree, dropping it is
perhaps the best. Presumably the linkage with the CXX compiler should only
be if the C++ bindings are enabled? This is almost always going to be the
case these days, but someone might want to compile a minimal C only
static library for embedded purposes?

> >3) I also get the following errors
> >
> >/usr/bin/ld: /home/andrew/software/plplot/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(wxwidgets_comms.cpp.o): undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
> >/lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from command line
> >collect2: error: ld returned 1 exit status
> >Makefile:103: recipe for target 'x00c' failed
> >make[1]: *** [x00c] Error 1
> >
> >which I think are probably due to librt not being linked explicitly? Alan
> >- I'm not quite sure where this needs fixing. Can you reproduce this on
> >Debian?
> 
> I cannot reproduce that issue (my comprehensive tests sailed through without issues
> for Debian stable).
> 
> There was an attempt to fix the rt issues prior to the 5.11.0 release,
> but it sounds like we missed something that matters on at least
> Ubuntu.
> 
> Here is where to look in our current source code for such fixes.
> 
> software@raven> find . -type f |grep -v .git |grep -v ChangeLog |xargs grep RT_LIB
> ./drivers/CMakeLists.txt:       ${RT_LIB}
> ./src/CMakeLists.txt:  list(APPEND libplplot_LINK_LIBRARIES ${RT_LIB})
> ./cmake/modules/wxwidgets.cmake:    # So only define RT_LIB for the Unix but not Mac case.
> ./cmake/modules/wxwidgets.cmake:      find_library(RT_LIB rt)
> ./cmake/modules/wxwidgets.cmake:      if(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:        message(STATUS "RT_LIB = ${RT_LIB}")
> ./cmake/modules/wxwidgets.cmake:      else(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:        set(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:      endif(RT_LIB)
> ./cmake/modules/wxwidgets.cmake:      set(RT_LIB)
> ./utils/CMakeLists.txt:  target_link_libraries(wxPLViewer plplotwxwidgets plplotcxx ${wxwidgets_LINK_FLAGS} ${MATH_LIB} ${RT_LIB})
> 
> If that message result from cmake shows you are finding the rt library
> on Ubuntu without issues, then for the static case the code in
> src/CMakeListx.txt is what you should look at to see why that rt
> library is not being included properly when building libplplot (which
> contains the wxwidgets code which refers to rt symbols).

RT_LIB is set fine, and it all works for the cmake builds, it's only the
traditional example build which fails, so I suspect this is a problem with
-lrt not being included in the pkg-config files for some reason. I'll
delve further.

Andrew

Re: [Plplot-devel] Comprehensive Testing: Ubuntu 14:10

[Alan W. I. <ir...@be...>]

On 2015-04-18 17:00-0700 Alan W. Irwin wrote:

> On 2015-04-18 22:56+0100 Andrew Ross wrote:
[....]
>> 2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
>> me. 
[....]
>
> The problem is that libplplot is a mixed C and C++ library for the
> nondynamic or static case (because of including C++ drivers code in
> the library for those cases).  Therefore, for the traditional build
> system for the installed examples, when gcc is used to link a C
> example a specific link to libstdc++.so has to be provided.
>
> The code in src/CMakeLists.txt to find that library is really ugly,
> works only for g++ and no other C++ compiler, and depends on g++
> internals which apparently have now changed.  And colon separation
> when there are drive letters is a real pain to deal with.  So I plan
> to abandon that code completely and simply solve the problem
> in a general way for the static and nondyamic cases by using the CXX
> compiler (which automatically links in libstdc++.so) for building
> the C examples using the traditional build system. Implementation
> to follow....

I have now (commit id d8d9999) implemented and tested that change.  Please check
that it works also for you.

One peculiarity that occurred for examples/c/x08c.c is that the C++
compiler apparently treats explicit declarations in the code
differently than those same declarations in headers.  So the explicit
declaration of plexit failed to work while replacing that with
#include "plplotP.h" to declare plexit (which I did in the above
commit) worked fine. Can any C++ expert here explain this peculiarity
of that language?

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
__________________________

Re: [Plplot-devel] Wrestling library linkage experiments.

[Alan W. I. <ir...@be...>]

On 2015-04-18 15:53-0700 Greg Jung wrote:

> Everything is now called "libplplot.dll" and precisely what I'm trying
> to do, to get a different name for libplplot.  The install prefix will
> direct it to a
> certain directory but the actual dll that is picked up is found from
> $path/{libname}.dll, irrespective of where it was built from.  I
> suppose in Linux it will go to the directory of origin, in windows it
> does not.

Why not set your PATH to find the installed version you want?

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
__________________________

Re: [Plplot-devel] Comprehensive Testing: Ubuntu 14:10

[Alan W. I. <ir...@be...>]

On 2015-04-18 22:56+0100 Andrew Ross wrote:

>
> Alan,
>
> I've finally got time to rerun my comnprehensive tests with Ubuntu 14.10
> and try to debug the niggle issues I encountered with the static build
>
> (My only change from last time is that I've had to build cmake from source
> to get a new enough version - I'm using 3.2.2)
[...]
> 2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
> me. The comments suggest that g++ returns a semicolon delimited list of
> paths, which is just like a cmake list so no manipulation is needed. At
> least on my system it is actually colon separated. Replacing the colons
> with semicolons fixes the problem and ensures the correct linkage options
> for pkg-config, and hence the traditional examples build. I've not
> commited this fix, since it might upset other people. In particularly on
> windows the colon may be used for drive letters? Can others check
> what g++ returns to check that a simple replacement of colons with
> semicolons wouldn't break anything? Try g++ --verbose --version and look
> at what LIBRARY_PATH is set to.

The problem is that libplplot is a mixed C and C++ library for the
nondynamic or static case (because of including C++ drivers code in
the library for those cases).  Therefore, for the traditional build
system for the installed examples, when gcc is used to link a C
example a specific link to libstdc++.so has to be provided.

The code in src/CMakeLists.txt to find that library is really ugly,
works only for g++ and no other C++ compiler, and depends on g++
internals which apparently have now changed.  And colon separation
when there are drive letters is a real pain to deal with.  So I plan
to abandon that code completely and simply solve the problem
in a general way for the static and nondyamic cases by using the CXX
compiler (which automatically links in libstdc++.so) for building
the C examples using the traditional build system. Implementation
to follow....

> 3) I also get the following errors
>
> /usr/bin/ld: /home/andrew/software/plplot/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(wxwidgets_comms.cpp.o): undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
> /lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> Makefile:103: recipe for target 'x00c' failed
> make[1]: *** [x00c] Error 1
>
> which I think are probably due to librt not being linked explicitly? Alan
> - I'm not quite sure where this needs fixing. Can you reproduce this on
> Debian?

I cannot reproduce that issue (my comprehensive tests sailed through without issues
for Debian stable).

There was an attempt to fix the rt issues prior to the 5.11.0 release,
but it sounds like we missed something that matters on at least
Ubuntu.

Here is where to look in our current source code for such fixes.

software@raven> find . -type f |grep -v .git |grep -v ChangeLog |xargs grep RT_LIB
./drivers/CMakeLists.txt:       ${RT_LIB}
./src/CMakeLists.txt:  list(APPEND libplplot_LINK_LIBRARIES ${RT_LIB})
./cmake/modules/wxwidgets.cmake:    # So only define RT_LIB for the Unix but not Mac case.
./cmake/modules/wxwidgets.cmake:      find_library(RT_LIB rt)
./cmake/modules/wxwidgets.cmake:      if(RT_LIB)
./cmake/modules/wxwidgets.cmake:        message(STATUS "RT_LIB = ${RT_LIB}")
./cmake/modules/wxwidgets.cmake:      else(RT_LIB)
./cmake/modules/wxwidgets.cmake:        set(RT_LIB)
./cmake/modules/wxwidgets.cmake:      endif(RT_LIB)
./cmake/modules/wxwidgets.cmake:      set(RT_LIB)
./utils/CMakeLists.txt:  target_link_libraries(wxPLViewer plplotwxwidgets plplotcxx ${wxwidgets_LINK_FLAGS} ${MATH_LIB} ${RT_LIB})

If that message result from cmake shows you are finding the rt library
on Ubuntu without issues, then for the static case the code in
src/CMakeListx.txt is what you should look at to see why that rt
library is not being included properly when building libplplot (which
contains the wxwidgets code which refers to rt symbols).

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
__________________________

Re: [Plplot-devel] Wrestling library linkage experiments.

[Alan W. I. <ir...@be...>]

On 2015-04-17 07:47-0700 Greg Jung wrote:

> Hi guys,
>  I have one specific plplot question then I will give a lot of
> background info that I'm fairly certain would come up in the ensuing
> Q/A for the issue.  The foreground is, I'm building GDL on mingw32,
> GDL wants to (optionally) bring in  a number of  libraries to
> accomplish added functionalities.
>
> The Question:
>   How do I get a specially-named libplplot version to function?  I
> wish to have libplplot-v2.dll be the shared that libplplot.dll.a is an
> import for - built and held in a directory  separately specified.  A
> copy of libplplot-v2.dll is then kept in the runtime path alongside
> the standard versions libplplot.dll, libplplotcxx.dll, wingcc.dll,
> etc.
> v2 version is actually "nodyn" - all of the same source except dynamic
> drivers are not enabled.

Hi Greg:

It sounds like for some reason you want/need two different plplot
libraries, one with and one without dynamic linking.  The safe (and
also the most covenient) way to implement that is two separate builds
and installs with two separate install prefixes.

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
__________________________

[Plplot-devel] Comprehensive Testing: Ubuntu 14:10

[Andrew R. <and...@us...>]

Alan,

I've finally got time to rerun my comnprehensive tests with Ubuntu 14.10
and try to debug the niggle issues I encountered with the static build

(My only change from last time is that I've had to build cmake from source
to get a new enough version - I'm using 3.2.2)

1) Warnings about conversion from string constant to char *. This is now
fixed by making pl_MenuStr and pl_DevName const char * not char *. These
variables are constant so the change should have no effect other than to
silence the warning.

2) The code in src/CMakeFiles to find the stdc++ library doesn't work for
me. The comments suggest that g++ returns a semicolon delimited list of
paths, which is just like a cmake list so no manipulation is needed. At
least on my system it is actually colon separated. Replacing the colons
with semicolons fixes the problem and ensures the correct linkage options
for pkg-config, and hence the traditional examples build. I've not
commited this fix, since it might upset other people. In particularly on
windows the colon may be used for drive letters? Can others check
what g++ returns to check that a simple replacement of colons with
semicolons wouldn't break anything? Try g++ --verbose --version and look
at what LIBRARY_PATH is set to. 

3) I also get the following errors

/usr/bin/ld: /home/andrew/software/plplot/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(wxwidgets_comms.cpp.o): undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/librt.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:103: recipe for target 'x00c' failed
make[1]: *** [x00c] Error 1

which I think are probably due to librt not being linked explicitly? Alan
- I'm not quite sure where this needs fixing. Can you reproduce this on
Debian?

Regards

Andrew

Re: [Plplot-devel] Wrestling library linkage experiments.

[Greg J. <gv...@gm...>]

That's exactly what I'd like to do, and dlltool (of mingw)  is
supposed to allow that, but it only went so far and left some missing
references, so I just assume it isn't up to the task for such a large
collection.  Hence my second approach was to fudge-in the name by
modifying the output of gcc when the library is created.
  That method works to allow a build, but runtime, it doesn't seem to
operate correctly.  Next try will be to repurpose the use of
${LIB_TAG} from the old Cmake build files and have libplplot10-nd type
names - with corresponding names of the import-libraries.
  I'm shooting in the dark, though, as Its unclear to me that
compatibility will be independent of the options used in the creation.

On Sat, Apr 18, 2015 at 5:28 AM, Arjen Markus <Arj...@de...> wrote:
> Hi Greg,
>
>
>
> I am not sure I understand exactly what you are trying to achieve (and I
> have only briefly looked at your explanation of the background), but have a
> look at the Fortran bindings. Here we explicitly use a .def file to export
> the various routines. The thing is that such a .def file allows the
> specification of the name of the DLL _independently_ of the name of the
> produced import library. (I made a mistake not too long with that LIBRARY
> statement, hence I know that it works this way).
>
>
>
> Of course this only works on platforms where a .def file is required, MinGW
> and Win32.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>> -----Original Message-----
>> From: Greg Jung [mailto:gv...@gm...]
>> Sent: Friday, April 17, 2015 4:48 PM
>> To: plp...@li...
>> Subject: [Plplot-devel] Wrestling library linkage experiments.
>>
>> Hi guys,
>>   I have one specific plplot question then I will give a lot of background
>> info that I'm
>> fairly certain would come up in the ensuing Q/A for the issue.  The
>> foreground is, I'm
>> building GDL on mingw32, GDL wants to (optionally) bring in  a number of
>> libraries
>> to accomplish added functionalities.
>>
>> The Question:
>>    How do I get a specially-named libplplot version to function?  I wish
>> to have
>> libplplot-v2.dll be the shared that libplplot.dll.a is an import for -
>> built and held in a
>> directory  separately specified.  A copy of libplplot-v2.dll is then kept
>> in the runtime
>> path alongside the standard versions libplplot.dll, libplplotcxx.dll,
>> wingcc.dll, etc.
>> v2 version is actually "nodyn" - all of the same source except dynamic
>> drivers are not
>> enabled.
>>
>> What I've been trying:
>>   I'm using a semi-updated plplot distribution from git Oct 7, 2014.
>> My first attempt was to use dlltool
>> to create an import library libplplot.dll.a which hooked into
>> libplplot-nodyn.dll, itself
>> created by simply renaming.  The link attempt failed so I went to the
>> build directory
>> and basically changed all references libplplot.dll to libplplot-nodyn.dll
>>
>> cat build.make | sed 's/libplplot.dll/libplplot-nodyn.dll/g' | sed
>> 's/libplplot-
>> nodyn.dll.a/libplplot.dll.a/g'
>>
>> (except that I did this in a text editor)
>>
>> This result worked to be successfully linked (and loaded, verified via
>> depends_x86.exe).
>>   But it doesn't work.
>> To see that the dysfunction is not in the code, I did the same procedure
>> for the plplot
>> version that was working, going to the original build directory, making a
>> shareable;
>> libplplot-sidyn.dll described by import library libplplot.dll.a - this
>> didn't work, either.
>>
>> -----------------------
>>
>> background:
>>
>>   I'm running on windows 7 (64 bit).  32-bit compiles are done using gcc
>> 4.9.2 built by
>> msys2; its all posix, dwarf2.
>>   In order to centralize the support libraries I keep those needed to run
>> programs in
>> c:/mingw/dll32-psxdw2 which is entered (via an NTFS junction) as
>> c:/usr/lib32 below:
>> PATH:
>>
>> C:\cmd:C:\cmd/bin:C:\usr/bin:C:\usr/bin32:C:\usr/bin32/mingw:C:\usr/lib32:C:\Windo
>> ws/system32:C:\Windows:C:\Windows/System32/Wbem
>>
>> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11/bin total
>> 1232
>> drwxr-xr-x 1 greg None      0 Apr 17 06:04 .
>> drwxr-xr-x 1 greg None      0 Apr 17 06:04 ..
>> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1
>> greg None
>> 188815 Apr 17 06:02 libplplotcxx.dll -rwxr-xr-x 1 greg None 512591 Apr 17
>> 06:02
>> libplplot-sidyn.dll -rwxr-xr-x 1 greg None 195307 Apr 17 06:02
>> libplplotwxwidgets.dll -
>> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1
>> greg None
>> 107360 Apr 17 06:02 pltek.exe
>>
>>  /d/bld/mingw32-psxdw2$ ls -la plplot11-SAVE/bin total 1236
>> drwxr-xr-x 1 greg None      0 Jan 28 16:53 .
>> drwxr-xr-x 1 greg None      0 Apr 17 05:33 ..
>> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1
>> greg None
>> 512079 Jan 28 14:54 libplplot.dll -rwxr-xr-x 1 greg None 188803 Jan 28
>> 14:54
>> libplplotcxx.dll -rwxr-xr-x 1 greg None 195295 Jan 28 14:54
>> libplplotwxwidgets.dll -
>> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1
>> greg None
>> 106848 Jan 28 14:55 pltek.exe
>>
>> and also, higher up the path, c:/usr/bin32, which keeps a hodge-podge of
>> libraries I
>> might be linking against for special reasons.
>>
>> $ ls -la /c/usr/bin32
>> total 14580
>> drwxr-xr-x 1 greg None        0 Apr 16 21:12 .
>> drwxr-xr-x 1 greg None        0 Mar 30 14:57 ..
>> -rwxr-xr-x 1 greg None 12328473 Mar 30 14:29 gdl.exe
>> -rwxr-xr-x 1 greg None   203638 Apr  5 22:28 libcsironn.dll
>> -rwxr-xr-x 1 greg None   186311 Apr  5 22:28 libplplotcxxd.dll
>> -rwxr-xr-x 1 greg None   572150 Apr  5 22:28 libplplotd.dll
>> -rwxr-xr-x 1 greg None  1107048 Apr 16 17:42 libplplot-nodyn.dll
>> -rwxr-xr-x 1 greg None   512591 Apr 17 06:02 libplplot-sidyn.dll
>> lrwxrwxrwx 1 greg None       12 Mar  7 19:51 mingw -> /mingw32/bin
>>
>>
>> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11/bin total
>> 1232
>> drwxr-xr-x 1 greg None      0 Apr 17 06:04 .
>> drwxr-xr-x 1 greg None      0 Apr 17 06:04 ..
>> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1
>> greg None
>> 188815 Apr 17 06:02 libplplotcxx.dll -rwxr-xr-x 1 greg None 512591 Apr 17
>> 06:02
>> libplplot-sidyn.dll -rwxr-xr-x 1 greg None 195307 Apr 17 06:02
>> libplplotwxwidgets.dll -
>> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1
>> greg None
>> 107360 Apr 17 06:02 pltek.exe
>>
>> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11-SAVE/bin
>> total
>> 1236
>> drwxr-xr-x 1 greg None      0 Jan 28 16:53 .
>> drwxr-xr-x 1 greg None      0 Apr 17 05:33 ..
>> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1
>> greg None
>> 512079 Jan 28 14:54 libplplot.dll -rwxr-xr-x 1 greg None 188803 Jan 28
>> 14:54
>> libplplotcxx.dll -rwxr-xr-x 1 greg None 195295 Jan 28 14:54
>> libplplotwxwidgets.dll -
>> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1
>> greg None
>> 106848 Jan 28 14:55 pltek.exe
>>
>> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la /c/mingw/dll32-psxdw2
>> |
>> grep Jan\ 28
>> -rwxr-xr-x 1 greg None   143271 Jan 28 14:54 cairo.dll
>> -rwxr-xr-x 1 greg None   118558 Jan 28 14:54 libcsirocsa.dll
>> -rwxr-xr-x 1 greg None   512079 Jan 28 14:54 libplplot.dll
>> -rwxr-xr-x 1 greg None   188803 Jan 28 14:54 libplplotcxx.dll
>> -rwxr-xr-x 1 greg None   195295 Jan 28 14:54 libplplotwxwidgets.dll
>> -rwxr-xr-x 1 greg None   120392 Jan 28 14:54 libqsastime.dll
>> -rwxr-xr-x 1 greg None    90308 Jan 28 14:54 mem.dll
>> -rwxr-xr-x 1 greg None    82507 Jan 28 14:54 null.dll
>> -rwxr-xr-x 1 greg None   120304 Jan 28 14:54 ps.dll
>> -rwxr-xr-x 1 greg None   108182 Jan 28 14:54 svg.dll
>> -rwxr-xr-x 1 greg None   114481 Jan 28 14:54 wingcc.dll
>> -rwxr-xr-x 1 greg None   499063 Jan 28 14:55 wxwidgets.dll
>> -rwxr-xr-x 1 greg None   100481 Jan 28 14:55 xfig.dll
>>
>>
>> ------------------------------------------------------------------------------
>> 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=V
>> A_SF
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Alan W. I. <ir...@be...>]

Hi Arjen:

Changing the subject line for obvious reasons.

On 2015-04-18 14:12-0000 Arjen Markus wrote:

> Here are the results for MinGW32/MSYS - this fails with the
well-known problem of the example not finding the PLplot library.
Actually: the progress of the testing script simply halts (as
witnessed by there no additional messages being written to the output
files) and the executable x00c.exe being in the list of processes
without any activity.

Your actual script output is
[...]
This variable specifies whether any windows platform has been detected
ANY_WINDOWS_PLATFORM=true

Each of the steps in this comprehensive test may take a while....
Prepend
/d/plplot-svn/plplot-git/../comprehensive_test_disposeable/shared/build_tree/dll
to the original PATH
cmake in the build tree
make VERBOSE=1 test_noninteractive in the build tree
ERROR: make test_noninteractive failed in the build tree

So the windows detection is working and so is the PATH manipulation to
put the dll subdirectory on the PATH.  The script does exit
with the above error message rather than just silently hanging.
So this seems like an ordinary error to me rather than a hang, but
I must admit that does not explain why x00c.exe continues to run after
it generated the error below.


If you look further at shared/output_tree/make_noninteractive.out
you have:
[...]
Generate C results for xfig file device
cd /D/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples && env EXAMPLES_DIR=D:/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples SRC_EXAMPLES_DIR=d:/plplot-svn/plplot-git/examples OUTPUT_DIR=D:/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples/test_examples_output_dir c:/MinGW/msys/1.0/bin/bash.exe D:/plplot-svn/comprehensive_test_disposeable/shared/build_tree/plplot_test/plplot-test.sh --verbose --front-end=c --device=xfig
Testing front-end c
x00c
make[3]: *** [examples/test_examples_output_dir/x01c01.xfig] Error 1
make[3]: Leaving directory `/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree'
make[2]: *** [examples/CMakeFiles/test_c_xfig.dir/all] Error 2
make[2]: Leaving directory `/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree'
make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
make[1]: Leaving directory `/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree'
make: *** [test_noninteractive] Error 2

So it appears that example is failing for unknown reasons (Error 1),
and there is no mention of not being able to find a dll.  Was there
some popup concerning this error that gave more information about it?

In sum, it seems to me the script is doing its job with
regard to Windows detection and PATH manipulation, and I have no
idea why the above run-time error occurred for the first attempt to
run any example.  So I am completely puzzled by these results.

Just to double check there isn't something fundamentally different now
about your MinGW/MSYS platform or how you set up that platform for
these tests can you now replicate your previous 5.11.0 good test
results with the brute-force approach?  For an exact attempt to
replicate what you did before, you should checkout the exact
commit id you used for your previous good tests, i.e.,

git checkout dadae4a

but I think checking out commit-id plplot-5.11.0
or current master tip should not make any difference
to whether the brute force technique works or not.

If in the end you have a clear case where master tip works with brute
force approach but it does not work without that brute force approach,
then I will have to look harder at what is going on with the PATH
manipulations in the script.  But I am virtually positive those
manipulations are fine now so my bet is there is some fundamental
change in your MinGW/MSYS platform or setup for that platform.

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
__________________________

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Alan W. I. <ir...@be...>]

On 2015-04-18 13:08-0000 Arjen Markus wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> Does this new robust logic for Windows detection now work for you?  (To make this
>> test of PATH manipulation much faster for our three main configurations [shared,
>> nondynamic, and static], I suggest you temporarily edit script.txt to drop all tests
>> other than the test_noninteractive one in both the build tree and installed examples
>> tree, using
>>
>> --do_ctest no
>> --do_test_interactive no
>> --do_test_traditional_install_tree no
>>
>> Please send back a full report (preferably with automatically generated tarball, see
>> above) whether this test succeeds or not.
>>

> I used the new logic and it seems to have worked up to some point.
See the attached tarball. The shared configuration worked fine, but
the tests failed on the nondynamic one. (Not automated yet, but that
is going to be my next step)

When rewriting this PATH manipulation logic after the 5.11.0 release I
screwed up one aspect (forgot the nondynamic case), and your test
found that script bug.  Sorry about that!  Please try again (for
commit id c689ff3 which fixes this issue).

Regardless of success or failure, full report please.

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
__________________________