plplot-devel

Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



I have attached the result of the comprehensive_test.sh script on Cygwin. This time I had an X server running, so that Tk is properly recognised as a valid option. The "shared" build succeeds, but the "nondynamic" build fails:



CMakeFiles/plplot.dir/__/bindings/tcl/tclAPI.c.o:tclAPI.c:(.text+0xacc): undefined reference to `__imp_plplotLibDir'

CMakeFiles/plplot.dir/__/bindings/tcl/tclAPI.c.o:tclAPI.c:(.text+0xacc): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_plplotLibDir'

collect2: error: ld returned 1 exit status



I guess this is due to confusion between static and dynamic linking - plplotLibDir has the attribute PLDLLIMPEXP. I have not tried to analyse the precise cause.



Regards,



Arjen


Arjen Markus
Sr. Adviseur/Onderzoeker
T

+31(0)88335 8559

E

arj...@de...




[Logo]<http://www.deltares.com/>

 www.deltares.com<http://www.deltares.com/>

Postbus 177
2600 MH Delft

[Deltares Twitter]
<http://www.twitter.com/deltares>

[Deltares LinkedIn]<http://www.linkedin.com/company/217430>

[Deltares Facebook]<https://www.facebook.com/pages/Deltares/154189334634001>



[Think before printing]Please consider the environment before printing this email


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 17, 2015 9:09 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and
> Ada
>
> On 2015-06-17 10:39-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> > Hm, something is failing in the non_dynamic tests:
> >
> > CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): undefined reference to
> `__imp_Pltcl_Init'
> >
> > CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): relocation truncated to fit:
> R_X86_64_PC32 against undefined symbol `__imp_Pltcl_Init'
> >
> > So your latest changes regarding the reduction of the llibraries for the non-dynamic
> drivers seem to have introduced a bug. I have attached the complete tarball.
>
> Hi Arjen:
>
> Thanks for this test.
>
> I. Comments on your setup of this test.
>
> For some reason there was a regression in your X setup so that you are now
> encountering that DISPLAY issue again.  The message (in
> cmake.out) was
>
> Application initialization failed: no display name and no $DISPLAY environment
> variable
>
> I encourage you to automate your X setup to avoid this regression in behaviour in
> future.
>
> Also please drop the -DENABLE_itk=OFF workaround which should not be
> necessary if you have all Tcl/Tk/Itcl/Itk/Iwidgets packages properly installed on
> Cygwin.  And if those are not properly installed, please fix that.
>
> Also, in retrospect it was a good idea for you to be cautious and test first with --
> do_test_interactive no.  But once the current issue is fixed, I will encourage you to
> drop that restriction so that all the Tcl, etc., interactive results can also be run-time
> tested.
>
> II. Comments on the bug you found.
>
> The link command that is failing above is (after line wrapping at each white space to
> help clarify the command and redacting the many irrelevant
> parts)
>
> /usr/bin/cc
> -Wl,--enable-auto-import
> CMakeFiles/pltcl.dir/pltcl.c.o
> -o
> pltcl.exe
> -Wl,--out-implib,libpltcl.dll.a
> -Wl,--major-image-version,0,--minor-image-version,0
> ../../dll/libplplottcltk_Main.dll.a
> /usr/lib/itcl3.4/libitcl3.4.dll.a
> -ltcl
> ../../dll/libplplot.dll.a
> [...]
> /usr/local/lib/libLASi.dll.a
> [...]
> /usr/local/lib/libshp.a
> [...]
>
> II A.  The /usr/local issue.
>
> Sorry I did not notice this issue before.  My assumption is that anything in /usr/local
> cannot be due to an official Cygwin install so should be avoided (at least for now).
> So to follow up on this I looked for "local" in cmake.out and found the following:
>
> -- TCL_INCLUDE_PATH = /usr/local/include
>
> -- FindShapelib: Found shapelib header directory, /usr/local/include, and library,
> /usr/local/lib/libshp.a.
>
> libplplot_LINK_FLAGS =
> /usr/lib/libltdl.dll.a;/usr/lib/libdl.a;/usr/local/lib/libshp.a;/usr/lib/libfreetype.dll.a;-
> lcsirocsa;-lcsironn;-lqhull;-lqsastime
>
> So please do the appropriate /usr/local renaming (perhaps of all of
> /usr/local) to force CMake to find the official Cygwin versions of Tcl, shapelib, and
> libLASi which I presume you have long-since already installed.  The result should be
> no mention of /usr/local in cmake.out the CMake cache files or any of your build
> commands.
>
> I suspect all those /usr/local results are leftovers from an epa_build attempt you did
> long ago.  At some point you might want to try epa_build again (but with an install
> prefix other that /usr/local so the results don't necessarily take CMake precedence
> over all others), but only after you make sure all the official Cygwin packages work.
>
> II B. The linking issue with pltcl that you discovered above.
>
> The above link command for pltcl shows that libplplot is properly linked.  So one
> possibility to explain this is either Pltcl_Init is not defined in the plplot library or it is
> defined in that library but not visible.  To check that, please use the nm command
> (which likely is already installed, but if not you should be able to find it in
> binutils-2.25-2) as follows:
>
> # Change to _nondynamic_ build directory
> cd ../comprehensive_test_disposeable/nondynamic/build_tree/
> # Build plplot library (which was cleaned by the script) in the # nondynamic case
> make plplot # Test for definition of Pltcl_Init in that library nm --defined-only
> <library_name> |grep Pltcl_Init
>
> where <library_name> is the appropriate name of the plplot library you just built.
> Here that is src/libplplot.so, but I am aware there are two locations (in src and in dll)
> of the plplot library for Cygwin, and I don't know which one you should be using with
> the nm command so you will have to experiment to find which to use with nm.
>
> The result of the above command here is
>
> 000000000008f120 T Pltcl_Init
>
> which indicates that symbol is defined in the plplot library and you should be getting
> something similar there.
>
> Once you have proved that symbol is defined in the plplot library the next issue is
> whether that symbol is externally visible.  "nm" tests symbol visibility with the --
> extern-only option, e.g.,
>
> nm --extern-only --defined-only <library_name> |grep Pltcl_Init
>
> and if Pltcl_Init is externally visible you should get the same result whether --extern-
> only is used or not.  And that proved to be the case here when I compiled with
>
> CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>
> which should make gcc act very similarly on Linux to the way it handles visibility
> issues for C or C++ library on Windows.
>
> So from my good visibility results here, I am pretty sure visibility should not be an
> issue for you there, but please get back to me with the Pltcl_Init definition and
> visibility results via the "nm" command for the plplot library for the nondynamic case
> to confirm that (or not), and we can take it from there.
>
> 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
> __________________________
>

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



I had a quick look at the source code: only the Tcl bindings use this global variable plplotLibDir to communicate the location of the library. If we use a small "setter" function instead, then the complications of exporting/importing a variable from the PLplot library is not needed anymore. Something like:



void pl_set_library_dir( char *dir ) {

    plplotLibDir = plstrdup(dir);

}

Regards,

Arjen

From: Arjen Markus [mailto:Arj...@de...]
Sent: Sunday, July 05, 2015 3:57 PM
To: Alan W. Irwin
Cc: plp...@li...
Subject: Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk


Hi Alan,



I have attached the result of the comprehensive_test.sh script on Cygwin. This time I had an X server running, so that Tk is properly recognised as a valid option. The "shared" build succeeds, but the "nondynamic" build fails:



CMakeFiles/plplot.dir/__/bindings/tcl/tclAPI.c.o:tclAPI.c:(.text+0xacc): undefined reference to `__imp_plplotLibDir'

CMakeFiles/plplot.dir/__/bindings/tcl/tclAPI.c.o:tclAPI.c:(.text+0xacc): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_plplotLibDir'

collect2: error: ld returned 1 exit status



I guess this is due to confusion between static and dynamic linking - plplotLibDir has the attribute PLDLLIMPEXP. I have not tried to analyse the precise cause.



Regards,



Arjen


Arjen Markus
Sr. Adviseur/Onderzoeker
T

+31(0)88335 8559

E

arj...@de...




[Logo]<http://www.deltares.com/>

 www.deltares.com<http://www.deltares.com/>

Postbus 177
2600 MH Delft

[Deltares Twitter]
<http://www.twitter.com/deltares>

[Deltares LinkedIn]<http://www.linkedin.com/company/217430>

[Deltares Facebook]<https://www.facebook.com/pages/Deltares/154189334634001>



[Think before printing]Please consider the environment before printing this email


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 17, 2015 9:09 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and
> Ada
>
> On 2015-06-17 10:39-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> > Hm, something is failing in the non_dynamic tests:
> >
> > CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): undefined reference to
> `__imp_Pltcl_Init'
> >
> > CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): relocation truncated to fit:
> R_X86_64_PC32 against undefined symbol `__imp_Pltcl_Init'
> >
> > So your latest changes regarding the reduction of the llibraries for the non-dynamic
> drivers seem to have introduced a bug. I have attached the complete tarball.
>
> Hi Arjen:
>
> Thanks for this test.
>
> I. Comments on your setup of this test.
>
> For some reason there was a regression in your X setup so that you are now
> encountering that DISPLAY issue again.  The message (in
> cmake.out) was
>
> Application initialization failed: no display name and no $DISPLAY environment
> variable
>
> I encourage you to automate your X setup to avoid this regression in behaviour in
> future.
>
> Also please drop the -DENABLE_itk=OFF workaround which should not be
> necessary if you have all Tcl/Tk/Itcl/Itk/Iwidgets packages properly installed on
> Cygwin.  And if those are not properly installed, please fix that.
>
> Also, in retrospect it was a good idea for you to be cautious and test first with --
> do_test_interactive no.  But once the current issue is fixed, I will encourage you to
> drop that restriction so that all the Tcl, etc., interactive results can also be run-time
> tested.
>
> II. Comments on the bug you found.
>
> The link command that is failing above is (after line wrapping at each white space to
> help clarify the command and redacting the many irrelevant
> parts)
>
> /usr/bin/cc
> -Wl,--enable-auto-import
> CMakeFiles/pltcl.dir/pltcl.c.o
> -o
> pltcl.exe
> -Wl,--out-implib,libpltcl.dll.a
> -Wl,--major-image-version,0,--minor-image-version,0
> ../../dll/libplplottcltk_Main.dll.a
> /usr/lib/itcl3.4/libitcl3.4.dll.a
> -ltcl
> ../../dll/libplplot.dll.a
> [...]
> /usr/local/lib/libLASi.dll.a
> [...]
> /usr/local/lib/libshp.a
> [...]
>
> II A.  The /usr/local issue.
>
> Sorry I did not notice this issue before.  My assumption is that anything in /usr/local
> cannot be due to an official Cygwin install so should be avoided (at least for now).
> So to follow up on this I looked for "local" in cmake.out and found the following:
>
> -- TCL_INCLUDE_PATH = /usr/local/include
>
> -- FindShapelib: Found shapelib header directory, /usr/local/include, and library,
> /usr/local/lib/libshp.a.
>
> libplplot_LINK_FLAGS =
> /usr/lib/libltdl.dll.a;/usr/lib/libdl.a;/usr/local/lib/libshp.a;/usr/lib/libfreetype.dll.a;-
> lcsirocsa;-lcsironn;-lqhull;-lqsastime
>
> So please do the appropriate /usr/local renaming (perhaps of all of
> /usr/local) to force CMake to find the official Cygwin versions of Tcl, shapelib, and
> libLASi which I presume you have long-since already installed.  The result should be
> no mention of /usr/local in cmake.out the CMake cache files or any of your build
> commands.
>
> I suspect all those /usr/local results are leftovers from an epa_build attempt you did
> long ago.  At some point you might want to try epa_build again (but with an install
> prefix other that /usr/local so the results don't necessarily take CMake precedence
> over all others), but only after you make sure all the official Cygwin packages work.
>
> II B. The linking issue with pltcl that you discovered above.
>
> The above link command for pltcl shows that libplplot is properly linked.  So one
> possibility to explain this is either Pltcl_Init is not defined in the plplot library or it is
> defined in that library but not visible.  To check that, please use the nm command
> (which likely is already installed, but if not you should be able to find it in
> binutils-2.25-2) as follows:
>
> # Change to _nondynamic_ build directory
> cd ../comprehensive_test_disposeable/nondynamic/build_tree/
> # Build plplot library (which was cleaned by the script) in the # nondynamic case
> make plplot # Test for definition of Pltcl_Init in that library nm --defined-only
> <library_name> |grep Pltcl_Init
>
> where <library_name> is the appropriate name of the plplot library you just built.
> Here that is src/libplplot.so, but I am aware there are two locations (in src and in dll)
> of the plplot library for Cygwin, and I don't know which one you should be using with
> the nm command so you will have to experiment to find which to use with nm.
>
> The result of the above command here is
>
> 000000000008f120 T Pltcl_Init
>
> which indicates that symbol is defined in the plplot library and you should be getting
> something similar there.
>
> Once you have proved that symbol is defined in the plplot library the next issue is
> whether that symbol is externally visible.  "nm" tests symbol visibility with the --
> extern-only option, e.g.,
>
> nm --extern-only --defined-only <library_name> |grep Pltcl_Init
>
> and if Pltcl_Init is externally visible you should get the same result whether --extern-
> only is used or not.  And that proved to be the case here when I compiled with
>
> CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>
> which should make gcc act very similarly on Linux to the way it handles visibility
> issues for C or C++ library on Windows.
>
> So from my good visibility results here, I am pretty sure visibility should not be an
> issue for you there, but please get back to me with the Pltcl_Init definition and
> visibility results via the "nm" command for the plplot library for the nondynamic case
> to confirm that (or not), and we can take it from there.
>
> 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
> __________________________
>
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.
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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Arjen:

Thanks for that report.

You said:

> I have attached the result of the comprehensive_test.sh script on
Cygwin. This time I had an X server running, so that Tk is properly
recognised as a valid option.

Good.  I hope this part of the X setup is put into your script that
sets up and runs scripts/comprehensive_test.sh so this issue will not
come back to haunt us again.

> The "shared" build succeeds, but the
"nondynamic" build fails:

There are some lingering but important Cygwin setup issues that you
should address just as soon as that is convenient for you.

I. As I mentioned before you are running scripts/comprehensive_test.sh
with

--cmake_added_options "-DENABLE_octave=OFF -DENABLE_ada=OFF -DENABLE_itk=OFF"

Please drop that last option, i.e., use

--cmake_added_options "-DENABLE_octave=OFF -DENABLE_ada=OFF"

instead to test my fix for the (default) -DENABLE_itk=ON case that I implemented
some time ago.

II. As I mentioned before these tests should be based strictly on
Cygwin packages rather than something you built and installed in
/usr/local at some unknown time in the past.  And given a choice,
CMake will always prefer to use the /usr/local version.  So I strongly
suggest you completely move /usr/local to somewhere else for the time
being to make sure you have a pure Cygwin result.

Here are environment variables that are set that involve usr/local.

irwin@raven> grep usr/local comprehensive_test_env.out 
PATH=/lib/python2.7/site-packages:/usr/local/bin:/usr/bin:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/d/CAF/bin:/cygdrive/c/GTK/bin:/cygdrive/c/tcl/bin:/cygdrive/c/windows/system32:/usr/lib/lapack
INFOPATH=/usr/local/info:/usr/share/info:/usr/info

These environmental variable results (which I assume are setup by
default on Cygwin) show that /usr/local/bin is on the PATH and
/usr/local/info is on the INFOPATH. That will be fine once you do the
above suggested move of /usr/local to somewhere else, but with your
present setup with /usr/local containing old results you have compiled
yourself, these settings for PATH and INFOPATH do contaminate your
results as seen below.

Here are the CMake results concerning usr/local.

irwin@raven> grep usr/local shared/output_tree/cmake.out
-- TCL_INCLUDE_PATH = /usr/local/include
-- FindShapelib: Found shapelib header directory, /usr/local/include, and library, /usr/local/lib/libshp.a.
-- tk_COMPILE_FLAGS = -I"/usr/local/include" -I"/usr/include" -I"/usr/include" -I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tcl -I"/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree"/bindings/tcl -I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tk
-- ntk_COMPILE_FLAGS = -I"/usr/local/include" -I"/usr/include" -I"/usr/include"
-- tkwin_COMPILE_FLAGS = -I"/usr/local/include" -I"/usr/include" -I"/usr/include" -I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tcl -I"/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree"/bindings/tcl -I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tk-x-plat -I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tk
libplplot_LINK_FLAGS = /usr/lib/libltdl.dll.a;/usr/lib/libdl.a;/usr/local/lib/libshp.a;/usr/lib/libfreetype.dll.a;-lcsirocsa;-lcsironn;-lqhull;-lqsastime

I assume all those /usr/local results being found by CMake will be
replaced by the correct pure Cygwin results once you do the suggested
renaming of /usr/local.  But, of course, you should check
shared/output_tree/cmake.out (generated very early in the test) to
make sure there are no warnings about missing components of PLplot
that correspond to a Cygwin package (e.g., the development package for
shapelib) that is not installed yet.

Please run another noninteractive test with the above issues
completely addressed as soon as is convenient.  You may find the
undefined-symbol issue you discovered for this test completely
disappears for that further test because there is no longer any chance
for inconsistency between pure Cygwin packages and /usr/local results
you have built yourself.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, July 05, 2015 10:48 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> Hi Arjen:
>
> Thanks for that report.
>
> You said:
>
> > I have attached the result of the comprehensive_test.sh script on
> Cygwin. This time I had an X server running, so that Tk is properly recognised as a
> valid option.
>
> Good.  I hope this part of the X setup is put into your script that sets up and runs
> scripts/comprehensive_test.sh so this issue will not come back to haunt us again.
>
> > The "shared" build succeeds, but the
> "nondynamic" build fails:
>
> There are some lingering but important Cygwin setup issues that you should address
> just as soon as that is convenient for you.
>
> I. As I mentioned before you are running scripts/comprehensive_test.sh with
>
> --cmake_added_options "-DENABLE_octave=OFF -DENABLE_ada=OFF -
> DENABLE_itk=OFF"
>
> Please drop that last option, i.e., use
>
> --cmake_added_options "-DENABLE_octave=OFF -DENABLE_ada=OFF"
>
> instead to test my fix for the (default) -DENABLE_itk=ON case that I implemented
> some time ago.
>
> II. As I mentioned before these tests should be based strictly on Cygwin packages
> rather than something you built and installed in /usr/local at some unknown time in
> the past.  And given a choice, CMake will always prefer to use the /usr/local version.
> So I strongly suggest you completely move /usr/local to somewhere else for the time
> being to make sure you have a pure Cygwin result.
>
Oh dear, I had hidden the Tcl libraries, but not the header files. Will redo that test now that these are also hidden.

> Here are environment variables that are set that involve usr/local.
>
> irwin@raven> grep usr/local comprehensive_test_env.out PATH=/lib/python2.7/site-
> packages:/usr/local/bin:/usr/bin:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygd
> rive/d/CAF/bin:/cygdrive/c/GTK/bin:/cygdrive/c/tcl/bin:/cygdrive/c/windows/system32:
> /usr/lib/lapack
> INFOPATH=/usr/local/info:/usr/share/info:/usr/info
>
> These environmental variable results (which I assume are setup by default on
> Cygwin) show that /usr/local/bin is on the PATH and /usr/local/info is on the
> INFOPATH. That will be fine once you do the above suggested move of /usr/local to
> somewhere else, but with your present setup with /usr/local containing old results
> you have compiled yourself, these settings for PATH and INFOPATH do
> contaminate your results as seen below.
>
> Here are the CMake results concerning usr/local.
>
> irwin@raven> grep usr/local shared/output_tree/cmake.out
> -- TCL_INCLUDE_PATH = /usr/local/include
> -- FindShapelib: Found shapelib header directory, /usr/local/include, and library,
> /usr/local/lib/libshp.a.
> -- tk_COMPILE_FLAGS = -I"/usr/local/include" -I"/usr/include" -I"/usr/include" -
> I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tcl -I"/cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree"/bindings/tcl -
> I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tk
> -- ntk_COMPILE_FLAGS = -I"/usr/local/include" -I"/usr/include" -I"/usr/include"
> -- tkwin_COMPILE_FLAGS = -I"/usr/local/include" -I"/usr/include" -I"/usr/include" -
> I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tcl -I"/cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/shared/build_tree"/bindings/tcl -
> I"/cygdrive/d/plplot-svn/plplot-git"/bindings/tk-x-plat -I"/cygdrive/d/plplot-svn/plplot-
> git"/bindings/tk
> libplplot_LINK_FLAGS =
> /usr/lib/libltdl.dll.a;/usr/lib/libdl.a;/usr/local/lib/libshp.a;/usr/lib/libfreetype.dll.a;-
> lcsirocsa;-lcsironn;-lqhull;-lqsastime
>
> I assume all those /usr/local results being found by CMake will be replaced by the
> correct pure Cygwin results once you do the suggested renaming of /usr/local.  But,
> of course, you should check shared/output_tree/cmake.out (generated very early in
> the test) to make sure there are no warnings about missing components of PLplot
> that correspond to a Cygwin package (e.g., the development package for
> shapelib) that is not installed yet.
>
> Please run another noninteractive test with the above issues completely addressed
> as soon as is convenient.  You may find the undefined-symbol issue you discovered
> for this test completely disappears for that further test because there is no longer any
> chance for inconsistency between pure Cygwin packages and /usr/local results you
> have built yourself.
>
Hm, it seems that the shapelib library was installed under /usr/local, as well as the LibLASi static library. I did not compile them myself.

I have renamed the original /usr/local and created an empty one now, let us see what this brings.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



Alas, the error I reported persists, even now that /usr/local plays no role anymore in the build. See the attached tarball.

(To get Itk to work I had to install Iwidgets, but once that was done, it was accepted by CMake.)


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, July 05, 2015 10:48 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> Hi Arjen:
>
> Thanks for that report.
>
> You said:
>
>
> Please run another noninteractive test with the above issues completely addressed
> as soon as is convenient.  You may find the undefined-symbol issue you discovered
> for this test completely disappears for that further test because there is no longer any
> chance for inconsistency between pure Cygwin packages and /usr/local results you
> have built yourself.
>
> Alan


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 on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-07-06 16:11-0000 Arjen Markus wrote:

> Alas, the error I reported persists, even now that /usr/local plays
no role anymore in the build. See the attached tarball.

Hi Arjen:

I was happy to see that the Cygwin itk fix I implemented a while back
actually works for you and that all the /usr/local stuff is no longer
contaminating the result in your report.  Your elimination of the
possibility of such contamination will be a big help in finding the
source of the remaining issue you are reporting.

With regard to that issue, I still think it is some visibility problem
since the code that defines the missing symbol should be part of
the PLplot library for the nondynamic case. So could you check both
the definition and visibility of that missing symbol in the PLplot
library for the nondynamic case using the nm method I suggested
before?  i.e.,

# change directory to the nondynamic build tree
cd nondynamic/build_tree/

# Check for symbol definition in PLplot library
nm --defined-only <plplot library location> |grep plplotLibDir

# Check for symbol visibility in PLplot library
nm --defined-only --extern-only <plplot library location> |grep plplotLibDir

Thanks in advance.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-07-06 10:43-0700 Alan W. Irwin wrote:

> On 2015-07-06 16:11-0000 Arjen Markus wrote:
>
>> Alas, the error I reported persists, even now that /usr/local plays
> no role anymore in the build. See the attached tarball.
>
> Hi Arjen:
>
> I was happy to see that the Cygwin itk fix I implemented a while back
> actually works for you and that all the /usr/local stuff is no longer
> contaminating the result in your report.  Your elimination of the
> possibility of such contamination will be a big help in finding the
> source of the remaining issue you are reporting.
>
> With regard to that issue, I still think it is some visibility problem
> since the code that defines the missing symbol should be part of
> the PLplot library for the nondynamic case. So could you check both
> the definition and visibility of that missing symbol in the PLplot
> library for the nondynamic case using the nm method I suggested
> before?  i.e.,
>
> # change directory to the nondynamic build tree
> cd nondynamic/build_tree/
>
> # Check for symbol definition in PLplot library
> nm --defined-only <plplot library location> |grep plplotLibDir
>
> # Check for symbol visibility in PLplot library
> nm --defined-only --extern-only <plplot library location> |grep plplotLibDir
>
> Thanks in advance.

Hi Arjen:

I followed up by doing my own comprehensive test on Linux, and I
cannot replicate what I anticipate will be your report of visibility
issues from the experiments above.  For example, for the nondynamic
case I get

software@raven> nm --defined-only --extern-only src/libplplot.so |grep plplotLibDir
00000000002cdd10 B plplotLibDir

i.e., plplotLibDir is both defined and visible in the PLplot library
built on the Linux platform for the nondynamic case.

However, I then looked further at where plplotLibDir was defined, and
I found the following line that does that in

bindings/tcl/tclAPI.c

extern PLDLLIMPORT char * plplotLibDir;


But that is a non-standard use of PLDLLIMPORT.  In fact, the only other
place I can find it in our code base (other than in include/pldll.h.in) is in

software@raven> find . -type f |grep -v .git |xargs grep PLDLLIMPORT |grep -v pldll.h
./bindings/tcl/tclAPI.c:extern PLDLLIMPORT char * plplotLibDir;
./include/plplotP.h:// extern PLStream PLDLLIMPORT *plsc;

and in that latter case that commented out code was replaced by

extern PLDLLIMPEXP_DATA( PLStream * ) plsc;

The net result of this is I am positive that for best visibility
results on all platforms

extern PLDLLIMPORT char * plplotLibDir;

should be replaced by

extern PLDLLIMPEXP_TCLTK_DATA( char * ) plplotLibDir;

I have done that change (as of commit ae0e9da) and comprehensively tested it
on Linux with no visibility issues showing up for those
tests.

So please try running scripts/comprehensive_test.sh again to see if ae0e9da solves
this final noninteractive issue completely for Cygwin (which would be a
new high in Cygwin comprehensive testing).

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



Well, that was spot on :). See the attached tarball. The test script completed without any complaints and the comparisons are clean.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> The net result of this is I am positive that for best visibility results on all platforms
>
> extern PLDLLIMPORT char * plplotLibDir;
>
> should be replaced by
>
> extern PLDLLIMPEXP_TCLTK_DATA( char * ) plplotLibDir;
>
> I have done that change (as of commit ae0e9da) and comprehensively tested it on
> Linux with no visibility issues showing up for those tests.
>
> So please try running scripts/comprehensive_test.sh again to see if ae0e9da solves
> this final noninteractive issue completely for Cygwin (which would be a new high in
> Cygwin comprehensive testing).
>
> Alan


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 on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-07-07 05:53-0000 Arjen Markus wrote:

> Well, that was spot on :). See the attached tarball. The test script completed without any complaints and the comparisons are clean.

Hi Arjen:

I agree with your conclusions about the the clean nature of these
results for the largest number of PLplot components tested on Cygwin
so far.  My thanks for your essential help in achieving this high
point for Cygwin!

That said, your report does indicate there is still one noninteractive issue
that we should deal with for this release cycle, and my apologies for
missing it until now. Your latest result uses

cmake_added_options=-DENABLE_octave=OFF -DENABLE_ada=OFF

to workaround some build system issues on the Cygwin platform.
-DENABLE_octave=OFF is something you adopted on June 3rd after installing the
final Octave-related Cygwin package that was required.  Your comment
back then was

-        Allowing Octave gave Cmake errors about two versus four
arguments. I turned that off.

As far as I know we never followed up further on this build-system
issue for configuring the Octave binding of PLplot, but I would like
to do that now.

So when you get a change could you run the script again
without -DENABLE_octave=OFF so I can diagnose (and hopefully fix) this
issue?

I believe this issue will be the last noninteractive one I will
attempt to deal with for the Cygwin platform in this release cycle.
Of course, you also use -DENABLE_ada=OFF to workaround the well-known
Ada language support issue on Cygwin, but I expect you will be
continuing with that workaround indefinitely because it is likely I
will only be able to deal with this issue some time after the planned
5.11.1 release.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



Well, I tried it with Octave allowed, but I get build errors - see the tarball. It does not seem to be complaining about 2 versus 4 arguments anymore, but something is definitely wrong. Could that be the SWIG version? (Note: I did not use the very latest checkout, but the commits I saw have nothing to do with Octave).



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, July 07, 2015 9:21 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> On 2015-07-07 05:53-0000 Arjen Markus wrote:
>
> > Well, that was spot on :). See the attached tarball. The test script completed
> without any complaints and the comparisons are clean.
>
> Hi Arjen:
>
> I agree with your conclusions about the the clean nature of these results for the
> largest number of PLplot components tested on Cygwin so far.  My thanks for your
> essential help in achieving this high point for Cygwin!
>
> That said, your report does indicate there is still one noninteractive issue that we
> should deal with for this release cycle, and my apologies for missing it until now.
> Your latest result uses
>
> cmake_added_options=-DENABLE_octave=OFF -DENABLE_ada=OFF
>
> to workaround some build system issues on the Cygwin platform.
> -DENABLE_octave=OFF is something you adopted on June 3rd after installing the
> final Octave-related Cygwin package that was required.  Your comment back then
> was
>
> -        Allowing Octave gave Cmake errors about two versus four
> arguments. I turned that off.
>
> As far as I know we never followed up further on this build-system issue for
> configuring the Octave binding of PLplot, but I would like to do that now.
>
> So when you get a change could you run the script again without -
> DENABLE_octave=OFF so I can diagnose (and hopefully fix) this issue?
>
> I believe this issue will be the last noninteractive one I will attempt to deal with for the
> Cygwin platform in this release cycle.
> Of course, you also use -DENABLE_ada=OFF to workaround the well-known Ada
> language support issue on Cygwin, but I expect you will be continuing with that
> workaround indefinitely because it is likely I will only be able to deal with this issue
> some time after the planned
> 5.11.1 release.
>
> 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
> __________________________

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-07-08 15:46-0000 Arjen Markus wrote:

> Well, I tried it with Octave allowed, but I get build errors - see
the tarball. It does not seem to be complaining about 2 versus 4
arguments anymore, but something is definitely wrong. Could that be
the SWIG version? (Note: I did not use the very latest checkout, but
the commits I saw have nothing to do with Octave).

To Arjen and Orion:

@Arjen:
Thanks for this comprehensive test report.

The short response for working around the octave error you
encountered is you should remove the Cygwin package
octave-devel-4.0.0-1 and install instead octave-devel-3.8.2-1. (And
you should also confirm you have libhdf5-devel-1.8.15-1 installed.)
And then you should try the test again (probably it is best if you do
that with the PLplot master tip version).  I am pretty sure that
will "just work" since the 2 versus 4 argument issue has now been fixed
and we have plenty of good tests of octave-3 on other platforms.

@Orion:

I suggest you also use Octave-3 for now assuming that Fedora has
Octave-3 packages.

@Arjen:

Here is my longer response to your report.

It turns out you ran into virtually exactly the same octave problems
that Orion reported here so you may want to reread his recent post
about this and my response to it.

The first part of Orion's post shows that the swig-3.0.6
octave component does not like leading blanks in documentation of the
swig-generated bindings for some reason, but swig-3.0.5 is OK with
that. I have fixed that issue as of the current master tip.  Your use
of ae0e9da misses that fix to our documentation of the swig-generated
bindings, but missing that fix did not matter for your case since
Cygwin currently supplies you with swig-3.0.5.

However, once Orion locally fixed the leading blank issue in our
documentation of swig-generated bindings (the issue that is now
permanently fixed in master tip), he went on to describe additional
issues with octave #includes supplied by swig that are not compatible
with Octave-4.0.0, and it appears you ran into those exact same
swig issues.

In sum, it appears build issues like you encountered above will not 
allow us to even try Octave-4.0.0 until swig fixes their Octave-4.0.0
#include issues, and that swig fix propagates to swig versions we are
using.  So for now (commit id 2ad5aef) the build system issues a
WARNING if it finds Octave-4.  For that case it disables the octave
bindings unless the user specifically opts in using the cmake
experimental option -DTRY_OCTAVE4=ON.

Once swig fixes their problem with Octave-4 #includes so that
-DTRY_OCTAVE4=ON has even a chance of working, I assume we will have a
lot of work ahead of us both in the octave bindings and octave
examples to become compatible with Octave-4.  So I expect
-DTRY_OCTAVE4=ON will be experimental for quite some time after the
required swig fix.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-07-08 14:36-0700 Alan W. Irwin wrote:

> In sum, it appears build issues like you encountered above will not
> allow us to even try Octave-4.0.0 until swig fixes their Octave-4.0.0
> #include issues, and that swig fix propagates to swig versions we are
> using.  So for now (commit id 2ad5aef) the build system issues a
> WARNING if it finds Octave-4.  For that case it disables the octave
> bindings unless the user specifically opts in using the cmake
> experimental option -DTRY_OCTAVE4=ON.

Note that commit id 2ad5aef had a bug ("3." was used for an
Octave version comparison check rather than "4.") which is addressed
in commit 0f72310.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



I uninstalled Octave 4 and installed 3.8, but when I ran the comprehensive test script, it got stuck somehow in the Cmake step, when it came to Octave. It did not advance for several minutes, so I broke it off. I then tried the ordinary Cmake and Make steps - without the X Window server as it happened - and that worked. Now I am running the comprehensive tests without X and it all seems to be going fine. More later, but there seems to be something in the octave-X connection which is hindering the automatic testing. Could be that it wants me to click in the X window, but I did not see anything specific, so that is something to look into later.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 08, 2015 11:37 PM
> To: Arjen Markus; Orion Poplawski
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> On 2015-07-08 15:46-0000 Arjen Markus wrote:
>
> > Well, I tried it with Octave allowed, but I get build errors - see
> the tarball. It does not seem to be complaining about 2 versus 4 arguments anymore,
> but something is definitely wrong. Could that be the SWIG version? (Note: I did not
> use the very latest checkout, but the commits I saw have nothing to do with Octave).
>
> To Arjen and Orion:
>
> @Arjen:
> Thanks for this comprehensive test report.
>
> The short response for working around the octave error you encountered is you
> should remove the Cygwin package
> octave-devel-4.0.0-1 and install instead octave-devel-3.8.2-1. (And you should also
> confirm you have libhdf5-devel-1.8.15-1 installed.) And then you should try the test
> again (probably it is best if you do that with the PLplot master tip version).  I am
> pretty sure that will "just work" since the 2 versus 4 argument issue has now been
> fixed and we have plenty of good tests of octave-3 on other platforms.
>
> @Orion:
>
> I suggest you also use Octave-3 for now assuming that Fedora has
> Octave-3 packages.
>
> @Arjen:
>
> Here is my longer response to your report.
>
> It turns out you ran into virtually exactly the same octave problems that Orion
> reported here so you may want to reread his recent post about this and my response
> to it.
>
> The first part of Orion's post shows that the swig-3.0.6 octave component does not
> like leading blanks in documentation of the swig-generated bindings for some reason,
> but swig-3.0.5 is OK with that. I have fixed that issue as of the current master tip.
> Your use of ae0e9da misses that fix to our documentation of the swig-generated
> bindings, but missing that fix did not matter for your case since Cygwin currently
> supplies you with swig-3.0.5.
>
> However, once Orion locally fixed the leading blank issue in our documentation of
> swig-generated bindings (the issue that is now permanently fixed in master tip), he
> went on to describe additional issues with octave #includes supplied by swig that are
> not compatible with Octave-4.0.0, and it appears you ran into those exact same swig
> issues.
>
> In sum, it appears build issues like you encountered above will not allow us to even
> try Octave-4.0.0 until swig fixes their Octave-4.0.0 #include issues, and that swig fix
> propagates to swig versions we are using.  So for now (commit id 2ad5aef) the build
> system issues a WARNING if it finds Octave-4.  For that case it disables the octave
> bindings unless the user specifically opts in using the cmake experimental option -
> DTRY_OCTAVE4=ON.
>
> Once swig fixes their problem with Octave-4 #includes so that -
> DTRY_OCTAVE4=ON has even a chance of working, I assume we will have a lot of
> work ahead of us both in the octave bindings and octave examples to become
> compatible with Octave-4.  So I expect -DTRY_OCTAVE4=ON will be experimental
> for quite some time after the required swig fix.
>
> 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
> __________________________

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



The Octave tests failed in the ctest step as you can see in the tarball. I have not found any indication as to why to it failed though.



Regards,



Arjen

From: Arjen Markus [mailto:Arj...@de...]
Sent: Thursday, July 09, 2015 7:12 Am
To: Alan W. Irwin; Orion Poplawski
Cc: plp...@li...
Subject: Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk


Hi Alan,



I uninstalled Octave 4 and installed 3.8, but when I ran the comprehensive test script, it got stuck somehow in the Cmake step, when it came to Octave. It did not advance for several minutes, so I broke it off. I then tried the ordinary Cmake and Make steps - without the X Window server as it happened - and that worked. Now I am running the comprehensive tests without X and it all seems to be going fine. More later, but there seems to be something in the octave-X connection which is hindering the automatic testing. Could be that it wants me to click in the X window, but I did not see anything specific, so that is something to look into later.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 08, 2015 11:37 PM
> To: Arjen Markus; Orion Poplawski
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> On 2015-07-08 15:46-0000 Arjen Markus wrote:
>
> > Well, I tried it with Octave allowed, but I get build errors - see
> the tarball. It does not seem to be complaining about 2 versus 4 arguments anymore,
> but something is definitely wrong. Could that be the SWIG version? (Note: I did not
> use the very latest checkout, but the commits I saw have nothing to do with Octave).
>
> To Arjen and Orion:
>
> @Arjen:
> Thanks for this comprehensive test report.
>
> The short response for working around the octave error you encountered is you
> should remove the Cygwin package
> octave-devel-4.0.0-1 and install instead octave-devel-3.8.2-1. (And you should also
> confirm you have libhdf5-devel-1.8.15-1 installed.) And then you should try the test
> again (probably it is best if you do that with the PLplot master tip version).  I am
> pretty sure that will "just work" since the 2 versus 4 argument issue has now been
> fixed and we have plenty of good tests of octave-3 on other platforms.
>
> @Orion:
>
> I suggest you also use Octave-3 for now assuming that Fedora has
> Octave-3 packages.
>
> @Arjen:
>
> Here is my longer response to your report.
>
> It turns out you ran into virtually exactly the same octave problems that Orion
> reported here so you may want to reread his recent post about this and my response
> to it.
>
> The first part of Orion's post shows that the swig-3.0.6 octave component does not
> like leading blanks in documentation of the swig-generated bindings for some reason,
> but swig-3.0.5 is OK with that. I have fixed that issue as of the current master tip.
> Your use of ae0e9da misses that fix to our documentation of the swig-generated
> bindings, but missing that fix did not matter for your case since Cygwin currently
> supplies you with swig-3.0.5.
>
> However, once Orion locally fixed the leading blank issue in our documentation of
> swig-generated bindings (the issue that is now permanently fixed in master tip), he
> went on to describe additional issues with octave #includes supplied by swig that are
> not compatible with Octave-4.0.0, and it appears you ran into those exact same swig
> issues.
>
> In sum, it appears build issues like you encountered above will not allow us to even
> try Octave-4.0.0 until swig fixes their Octave-4.0.0 #include issues, and that swig fix
> propagates to swig versions we are using.  So for now (commit id 2ad5aef) the build
> system issues a WARNING if it finds Octave-4.  For that case it disables the octave
> bindings unless the user specifically opts in using the cmake experimental option -
> DTRY_OCTAVE4=ON.
>
> Once swig fixes their problem with Octave-4 #includes so that -
> DTRY_OCTAVE4=ON has even a chance of working, I assume we will have a lot of
> work ahead of us both in the octave bindings and octave examples to become
> compatible with Octave-4.  So I expect -DTRY_OCTAVE4=ON will be experimental
> for quite some time after the required swig fix.
>
> 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
> __________________________
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.
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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Arjen:

First a comment about your Cygwin setup.

The cmake.out file revealed (as you mentioned in your first message) that
you are having trouble with X.  That sounds like exactly the same
problem that you intermittently had before.  Is it possible
installation of _any_ software on Cygwin means you have to go through
the whole X initialization procedure again? And if that proves to be
the case I hope you can automate that procedure so these intermittent
troubles with X disappear.

On 2015-07-09 05:42-0000 Arjen Markus wrote:

> The Octave tests failed in the ctest step as you can see in the
tarball. I have not found any indication as to why to it failed
though.

Thanks for that report.

The cmake.out results for finding Octave-3 look good.
And it appears there was no build error on Cygwin with our
Octave(-3) binding enabled which is good.

Of course, as you stated there is an obvious run-time error with
Octave on that platform, and ctest is not very informative about the
details of that error.  So I suggest you add the script options

--do_ctest no --build_command "make"

which will skip the uninformative ctest phase and also keep the build
non-parallel when building the test_noninteractive target (which is
the first thing done by the comprehensive test script if ctest is
skipped).

When the comprehensive test script builds that target it should run
into the same octave run-time errors as ctest only it will do that
verbosely and also in a non-parallel way which will show up in the
report tarball to help me to diagnose exactly what is wrong with the
octave component on Cygwin.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, July 09, 2015 10:30 AM
> To: Arjen Markus; Orion Poplawski
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> Hi Arjen:
>
> First a comment about your Cygwin setup.
>
> The cmake.out file revealed (as you mentioned in your first message) that you are
> having trouble with X.  That sounds like exactly the same problem that you
> intermittently had before.  Is it possible installation of _any_ software on Cygwin
> means you have to go through the whole X initialization procedure again? And if that
> proves to be the case I hope you can automate that procedure so these intermittent
> troubles with X disappear.
>
No, my script to start the comprehensive tests first starts the X Window server. When I leave out Octave, it all goes well, but with Octave I see that CMake does not continue after printing where it found Octave. I suspect something is waiting for input, but I do not yet have a clue what. As yesterday was my day to travel home, I did not have an opportunity to dig into it. So, instead I tried it without the X server running - this was just a lucky guess. And then I ran into the ctest problems.

> On 2015-07-09 05:42-0000 Arjen Markus wrote:
>
> > The Octave tests failed in the ctest step as you can see in the
> tarball. I have not found any indication as to why to it failed though.
>
> Thanks for that report.
>
> The cmake.out results for finding Octave-3 look good.
> And it appears there was no build error on Cygwin with our
> Octave(-3) binding enabled which is good.
>
> Of course, as you stated there is an obvious run-time error with Octave on that
> platform, and ctest is not very informative about the details of that error.  So I
> suggest you add the script options
>
> --do_ctest no --build_command "make"
>
> which will skip the uninformative ctest phase and also keep the build non-parallel
> when building the test_noninteractive target (which is the first thing done by the
> comprehensive test script if ctest is skipped).
>
> When the comprehensive test script builds that target it should run into the same
> octave run-time errors as ctest only it will do that verbosely and also in a non-parallel
> way which will show up in the report tarball to help me to diagnose exactly what is
> wrong with the octave component on Cygwin.
>
Okay, that is quite doable.  I will start the tests that way rightaway.

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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



The tarball indicates that the command "plplot_octave" was not found. Could it be that the subdirectory "dll" needs to be added to the LD_LIBRARY_PATH environment variable or perhaps to the PATH variable? I have not spent that much time on figuring this out - running the examples by hand was unsuccessful in a completely different way, but that is my ignorance regarding Octave (complaints about x00c not being the function file name "").



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Friday, July 10, 2015 8:41 AM
To: plp...@li...
Subject: Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk


Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, July 09, 2015 10:30 AM
> To: Arjen Markus; Orion Poplawski
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> Hi Arjen:
>
> First a comment about your Cygwin setup.
>
> The cmake.out file revealed (as you mentioned in your first message) that you are
> having trouble with X.  That sounds like exactly the same problem that you
> intermittently had before.  Is it possible installation of _any_ software on Cygwin
> means you have to go through the whole X initialization procedure again? And if that
> proves to be the case I hope you can automate that procedure so these intermittent
> troubles with X disappear.
>
No, my script to start the comprehensive tests first starts the X Window server. When I leave out Octave, it all goes well, but with Octave I see that CMake does not continue after printing where it found Octave. I suspect something is waiting for input, but I do not yet have a clue what. As yesterday was my day to travel home, I did not have an opportunity to dig into it. So, instead I tried it without the X server running - this was just a lucky guess. And then I ran into the ctest problems.

> On 2015-07-09 05:42-0000 Arjen Markus wrote:
>
> > The Octave tests failed in the ctest step as you can see in the
> tarball. I have not found any indication as to why to it failed though.
>
> Thanks for that report.
>
> The cmake.out results for finding Octave-3 look good.
> And it appears there was no build error on Cygwin with our
> Octave(-3) binding enabled which is good.
>
> Of course, as you stated there is an obvious run-time error with Octave on that
> platform, and ctest is not very informative about the details of that error.  So I
> suggest you add the script options
>
> --do_ctest no --build_command "make"
>
> which will skip the uninformative ctest phase and also keep the build non-parallel
> when building the test_noninteractive target (which is the first thing done by the
> comprehensive test script if ctest is skipped).
>
> When the comprehensive test script builds that target it should run into the same
> octave run-time errors as ctest only it will do that verbosely and also in a non-parallel
> way which will show up in the report tarball to help me to diagnose exactly what is
> wrong with the octave component on Cygwin.
>
Okay, that is quite doable.  I will start the tests that way rightaway.

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.
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 on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Arjen:

In response to your previous report of the full test with octave where
ctest failed virtually silently, I have tried to reproduce that
lack of information in ctest.out here by running a slightly
modified version of the script which moves
plplot_octave.oct to a different directory after it is built,
but instead for that case I got full error message from ctest.out, i.e.,

5: Test command: /bin/bash "-c" "EXAMPLES_DIR=/home/software/plplot/HEAD/comprehensive_test_disposeable/shared/build_tree/examples SRC_EXAMP
LES_DIR=/home/software/plplot/HEAD/plplot.git/examples OUTPUT_DIR=/home/software/plplot/HEAD/comprehensive_test_disposeable/shared/build_tre
e/ctest_examples_output_dir VC_CTEST_DIRECTORY= ./plplot-test.sh --verbose --device=psc --front-end=octave"
5: Test timeout computed to be: 1500
5: Testing front-end octave
5: /home/software/plplot/HEAD/comprehensive_test_disposeable/shared/build_tree/plplot_test/..
5: error: `plplot_octave' undefined near line 4 column 1
5: error: called from:
5: error:   /home/software/plplot/HEAD/comprehensive_test_disposeable/shared/build_tree/examples/../bindings/octave/plplot_stub.m at line 4, column 1
  2/26 Test  #5: examples_octave ..................***Failed    0.20 sec

So I am going to ascribe that lack of error messages in your case to some
subtle stderr or stdout bug in octave, bash, or ctest on Cygwin. Until
that is fixed, I suggest that if an "empty" ctest error message is
encountered on Cygwin, it is best to temporarily avoid that test as
you have done for your latest report below.

On 2015-07-10 07:18-0000 Arjen Markus wrote:

> The tarball indicates that the command "plplot_octave" was not
found. Could it be that the subdirectory "dll" needs to be added to
the LD_LIBRARY_PATH environment variable or perhaps to the PATH
variable? I have not spent that much time on figuring this out -
running the examples by hand was unsuccessful in a completely
different way, but that is my ignorance regarding Octave (complaints
about x00c not being the function file name "").

Thanks for that new report, and I agree with your analysis that octave
is looking in the wrong directory for plplot_octave.oct.  I believe I
have now fixed that issue (commit d645c88) so please try again.

Notice the d645c88 commit message includes a really simple test
(adapted from bindings/octave/USAGE) of the octave binding of PLplot
in the build tree that I did in addition to the comprehensive test
that I did of my change.  However, that simple test is an interactive
test (using -dev xwin) so will only work for you once you get your X
problems caused by the octave package install straightened out.

By the way, from his report it appears Greg has not encountered those
X problems even though he has installed octave.  And both his hardware
and Cygwin version are 64-bit just the same as your case. So the
"obvious" conclusion is you two should get identical comprehensive
test results, but so far that is not the case.

Instead, you have a weird thing going on with Octave and X on Cygwin, and he
is possibly (depending on your answer to my previous post) having a
weird thing going on with pysol and python compatibility on Cygwin.

I encourage you guys and Phil to pool your Cygwin expertise so you can
all learn how to avoid these weird problems that are interfering
with obtaining the best comprehensive tests on 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] Octave 4.0.0

[Orion P. <or...@co...>]

On 07/08/2015 03:36 PM, Alan W. Irwin wrote:
> On 2015-07-08 15:46-0000 Arjen Markus wrote:
> 
>> Well, I tried it with Octave allowed, but I get build errors - see
> the tarball. It does not seem to be complaining about 2 versus 4
> arguments anymore, but something is definitely wrong. Could that be
> the SWIG version? (Note: I did not use the very latest checkout, but
> the commits I saw have nothing to do with Octave).
> 
> To Arjen and Orion:
> 
> @Arjen:
> Thanks for this comprehensive test report.
> 
> The short response for working around the octave error you
> encountered is you should remove the Cygwin package
> octave-devel-4.0.0-1 and install instead octave-devel-3.8.2-1. (And
> you should also confirm you have libhdf5-devel-1.8.15-1 installed.)
> And then you should try the test again (probably it is best if you do
> that with the PLplot master tip version).  I am pretty sure that
> will "just work" since the 2 versus 4 argument issue has now been fixed
> and we have plenty of good tests of octave-3 on other platforms.
> 
> @Orion:
> 
> I suggest you also use Octave-3 for now assuming that Fedora has
> Octave-3 packages.
> 
> @Arjen:
> 
> Here is my longer response to your report.
> 
> It turns out you ran into virtually exactly the same octave problems
> that Orion reported here so you may want to reread his recent post
> about this and my response to it.
> 
> The first part of Orion's post shows that the swig-3.0.6
> octave component does not like leading blanks in documentation of the
> swig-generated bindings for some reason, but swig-3.0.5 is OK with
> that. I have fixed that issue as of the current master tip.  Your use
> of ae0e9da misses that fix to our documentation of the swig-generated
> bindings, but missing that fix did not matter for your case since
> Cygwin currently supplies you with swig-3.0.5.
> 
> However, once Orion locally fixed the leading blank issue in our
> documentation of swig-generated bindings (the issue that is now
> permanently fixed in master tip), he went on to describe additional
> issues with octave #includes supplied by swig that are not compatible
> with Octave-4.0.0, and it appears you ran into those exact same
> swig issues.
> 
> In sum, it appears build issues like you encountered above will not allow us
> to even try Octave-4.0.0 until swig fixes their Octave-4.0.0
> #include issues, and that swig fix propagates to swig versions we are
> using.  So for now (commit id 2ad5aef) the build system issues a
> WARNING if it finds Octave-4.  For that case it disables the octave
> bindings unless the user specifically opts in using the cmake
> experimental option -DTRY_OCTAVE4=ON.
> 
> Once swig fixes their problem with Octave-4 #includes so that
> -DTRY_OCTAVE4=ON has even a chance of working, I assume we will have a
> lot of work ahead of us both in the octave bindings and octave
> examples to become compatible with Octave-4.  So I expect
> -DTRY_OCTAVE4=ON will be experimental for quite some time after the
> required swig fix.
> 
> Alan
> __________________________
> Alan W. Irwin

My fix for octave 4.0,0 support in swig is here:

https://github.com/swig/swig/pull/460

I'll test builds of plplot once the swig build is complete.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] Octave 4.0.0

[Orion P. <or...@co...>]

On 07/10/2015 12:04 PM, Orion Poplawski wrote:
>
> My fix for octave 4.0,0 support in swig is here:
>
> https://github.com/swig/swig/pull/460
>
> I'll test builds of plplot once the swig build is complete.

plplot 5.11.0 is building fine in Rawhide with a patched swig 3.0.6, 
octave 4.0.0, and the patch to plplot for swig 3.0.6 doc issue.

http://koji.fedoraproject.org/koji/taskinfo?taskID=10334481


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  or...@co...
Boulder, CO 80301              http://www.cora.nwra.com

Re: [Plplot-devel] Octave 4.0.0

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

On 2015-07-11 17:52-0600 Orion Poplawski wrote:
>On 07/10/2015 12:04 PM, Orion Poplawski wrote:
>> 
>> My fix for octave 4.0,0 support in swig is here:
>> https://github.com/swig/swig/pull/460

> plplot 5.11.0 is building fine in Rawhide with a patched swig 3.0.6, octave 
> 4.0.0, and the patch to plplot for swig 3.0.6 doc issue.

Hi Orion:

Thanks for that encouraging news with regard to good builds of the
octave binding of PLplot against Octave-4.0.0.  But I have also been
concerned about the run-time results as well which you can
straightforwardly check there by simply running

cmake .... >& cmake.out
make test_diff_psc >& test_diff_psc.out

in an initially empty build tree.

Normally that test shows there are no differences between the
octave-generated and C-generated results for all our examples for the
Octave-3.x.y case.  If running that test there shows the same thing
for the Octave-4.0.0 case that is a very strong test of our octave
bindings for that case.

Regardless of whether you try such a run time check, your build
success motivates me to expand the epa_build implementation to see how
far I can get with an epa_build of Octave-4.0.0 and patched versions
of swig-2 and swig-3.  Assuming I can epa_build all of those, then
that would allow me to do the above run-time check here for patched
versions of both swig-2 and swig-3, and thus help build the case to
get your swig patch (or two variants of that if your patch has to be
modified for swig-2) into the next official releases of both swig-2
and swig-3.

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] Octave 4.0.0

[Orion P. <or...@co...>]

On 07/11/2015 08:27 PM, Alan W. Irwin wrote:
> On 2015-07-11 17:52-0600 Orion Poplawski wrote:
>> On 07/10/2015 12:04 PM, Orion Poplawski wrote:
>>>
>>> My fix for octave 4.0,0 support in swig is here:
>>> https://github.com/swig/swig/pull/460
> 
>> plplot 5.11.0 is building fine in Rawhide with a patched swig 3.0.6, octave
>> 4.0.0, and the patch to plplot for swig 3.0.6 doc issue.
> 
> Hi Orion:
> 
> Thanks for that encouraging news with regard to good builds of the
> octave binding of PLplot against Octave-4.0.0.  But I have also been
> concerned about the run-time results as well which you can
> straightforwardly check there by simply running
> 
> cmake .... >& cmake.out
> make test_diff_psc >& test_diff_psc.out
> 
> in an initially empty build tree.
> 
> Normally that test shows there are no differences between the
> octave-generated and C-generated results for all our examples for the
> Octave-3.x.y case.  If running that test there shows the same thing
> for the Octave-4.0.0 case that is a very strong test of our octave
> bindings for that case.
> 
> Regardless of whether you try such a run time check, your build
> success motivates me to expand the epa_build implementation to see how
> far I can get with an epa_build of Octave-4.0.0 and patched versions
> of swig-2 and swig-3.  Assuming I can epa_build all of those, then
> that would allow me to do the above run-time check here for patched
> versions of both swig-2 and swig-3, and thus help build the case to
> get your swig patch (or two variants of that if your patch has to be
> modified for swig-2) into the next official releases of both swig-2
> and swig-3.
> 
> Alan

I'm afraid that the plplot octave tests have been failing for quite a while in
Fedora Rawhide, probably due to gcc 5 as reported back in March.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] Octave 4.0.0

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

On 2015-07-11 19:27-0700 Alan W. Irwin wrote:
> [...Y]our build
> success motivates me to expand the epa_build implementation to see how
> far I can get with an epa_build of Octave-4.0.0 and patched versions
> of swig-2 and swig-3.  Assuming I can epa_build all of those, then
> that would allow me to do the above run-time check here for patched
> versions of both swig-2 and swig-3, and thus help build the case to
> get your swig patch (or two variants of that if your patch has to be
> modified for swig-2) into the next official releases of both swig-2
> and swig-3.

Hi Orion:

The current status of this effort is I am done with all the relevant
epa_build configuration, but the result segfaults at run time.

Here is what I have done so far.

1. Implemented an epa_build of lapack and blas.  ctest of that build
passed 100 per cent of all the many tests.

2. Upgraded the epa_build of swig-2.0.11 to swig-3.0.6 with your patch applied.
The result works well with PLplot for the non-octave case.  For
example, the swig-generated Python, Lua, and Java bindings all work
well.

3. Implemented an epa_build of octave_lite which is octave-4.0.0 with
all optional components disabled.  This version passes the simple test

octave:1> x=-pi:0.1:pi;
octave:2> plot(x,sin(x))
octave:3> exit

with the plot done with the default gnuplot.  However, valgrind of
that simple test loses control of octave_lite (see below).

4. epa_built plplot_lite against this octave-lite version with no issues.

5. However, when I try the above simple test in a directory which
contains the following file (to enable the PLplot version of plotting)

wine@raven> cat .octaverc
warning("off","Octave:shadowed-function");
addpath("/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/PLplot","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/PLplot/support","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/misc","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/examples/octave","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/bindings/octave","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/bindings/octave/PLplot");
global pl_automatic_replot
pl_automatic_replot=1;

where the form of this file has been suggested by bindings/octave/USAGE

the above simple plot test segfaults (where normally with PLplot built
against octave-3.x.y, this simple test generates a plot using the xwin device).

I would like to do further debugging of this segfault with valgrind,
but somehow valgrind is losing control of octave_lite so never
generates any messages after the normal burst of initial messages and
the commands go the same speed as usual (not the slow speed you
normally get with valgrind) regardless of whether I use gnuplot
(without segfault) or the .octaverc trick above to attempt to use
plplot (with segfault).

Tomorrow I will play with the configuration of the epa_build of
octave_lite to see if I can figure out a way to beat this valgrind
issue.

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] Octave 4.0.0

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

To Andrew and Orion:

I am handing off the octave-4 segfault issue that is described below
to you guys because I have run out of ideas and you both have more
octave/swig knowledge than I do.  There is a small bit at the end
where I solved all the valgrind reporting problems that were stopping
valgrind analysis, but the extremely simple run-time test of our
octave4 bindings still segfaults (presumably because the octave API
has changed significantly between octave 3 and octave 4), and I don't
know where to start to fix it because the full valgrind report
(attached as plplot_valgrind.out.gz) still isn't helping me very much.
But maybe one of you can figure it out or come up with an additional
octave option to make the valgrind results more useful for diagnosing
whatever the problem is that is causing the segfault.

More below.

On 2015-07-14 00:28-0700 Alan W. Irwin wrote:

> On 2015-07-11 19:27-0700 Alan W. Irwin wrote:
>> [...Y]our build
>> success motivates me to expand the epa_build implementation to see how
>> far I can get with an epa_build of Octave-4.0.0 and patched versions
>> of swig-2 and swig-3.  Assuming I can epa_build all of those, then
>> that would allow me to do the above run-time check here for patched
>> versions of both swig-2 and swig-3, and thus help build the case to
>> get your swig patch (or two variants of that if your patch has to be
>> modified for swig-2) into the next official releases of both swig-2
>> and swig-3.
>
> Hi Orion:
>
> The current status of this effort is I am done with all the relevant
> epa_build configuration, but the result segfaults at run time.
>
> Here is what I have done so far.
>
> 1. Implemented an epa_build of lapack and blas.  ctest of that build
> passed 100 per cent of all the many tests.
>
> 2. Upgraded the epa_build of swig-2.0.11 to swig-3.0.6 with your patch applied.
> The result works well with PLplot for the non-octave case.  For
> example, the swig-generated Python, Lua, and Java bindings all work
> well.
>
> 3. Implemented an epa_build of octave_lite which is octave-4.0.0 with
> all optional components disabled.  This version passes the simple test
>
> octave:1> x=-pi:0.1:pi;
> octave:2> plot(x,sin(x))
> octave:3> exit
>
> with the plot done with the default gnuplot.  However, valgrind of
> that simple test loses control of octave_lite (see below).
>
> 4. epa_built plplot_lite against this octave-lite version with no issues.
>
> 5. However, when I try the above simple test in a directory which
> contains the following file (to enable the PLplot version of plotting)
>
> wine@raven> cat .octaverc
> warning("off","Octave:shadowed-function");
> addpath("/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/PLplot","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/PLplot/support","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/misc","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/examples/octave","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/bindings/octave","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/bindings/octave/PLplot");
> global pl_automatic_replot
> pl_automatic_replot=1;
>
> where the form of this file has been suggested by bindings/octave/USAGE
>
> the above simple plot test segfaults (where normally with PLplot built
> against octave-3.x.y, this simple test generates a plot using the xwin device).
>
> I would like to do further debugging of this segfault with valgrind,
> but somehow valgrind is losing control of octave_lite so never
> generates any messages after the normal burst of initial messages and
> the commands go the same speed as usual (not the slow speed you
> normally get with valgrind) regardless of whether I use gnuplot
> (without segfault) or the .octaverc trick above to attempt to use
> plplot (with segfault).

That issue had a simple solution; for valgrind to trace octave4 requires
the valgrind option --trace-children=yes.  However, that in turn shows
a very extensive call stack where the number of callers is much larger
than the typical limit of 50 for --num-callers used for older valgrind
versions like provided by Debian wheezy.  Thus, to access a recent
valgrind version that allows --num-callers=500 at maximum, I epa_built
valgrind-3.10.1 (as opposed to Debian wheezy's 3.7.0).  And I generated
valgrind results with the following (wrapped) command:

/home/wine/newstart/build_script/install-linux_buildtools/bin/valgrind
--num-callers=500 --trace-children=yes octave 2>| plplot_valgrind.out

where I did the above simple test of the epa_built octave-4.0.0 in the directory where the above
.octaverc existed.  The segfault occurs and valgrind (as you can see
from the attached plplot_valgrind.out.gz) detects a couple of invalid
reads that presumably caused that segfault.

If I do exactly the same test (except for output file named
gnuplot_valgrind.out in a directory without that .octaverc,
then no segfault occurs, gnuplot plots the plot, and the valgrind
result (attached as gnuplot_valgrind.out.gz) is clean

However, I cannot proceed further than that because
plplot_valgrind.out.gz appears to contain no references to PLplot at
all. So I am completely stuck and handing off to you guys.

In any case, getting PLplot ready for octave4 is obviously
post-release material so my plan for the forthcoming release of 5.11.1
is the -DTRY_OCTAVE4=ON cmake option will remain highly experimental,
and unless the user sets that option our build system will either find
and use octave3 or disable octave altogether.

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
__________________________