plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] libieee.a is no more

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

On 2017-12-12 15:36-0700 Orion Poplawski wrote:

> Apparently glibc is dropping libieee.a in the next release.  In Fedora
> Rawhide, -mieee-fp on i686 results in:
>
> /usr/bin/ld: Cannot find -lieee
>
> Dropping -mieee-fp from csiro.cmake fixes it for me.

Hi Orion:

For i686 hardware and your patched case, what is the result of the test?

In other words, does the CMake output say

"Check for NaN awareness in C compiler - found"

or

"Check for NaN awareness in C compiler - not found"

followed by

WARNING: Setting PL_HAVE_QHULL and WITH_CSA to OFF.

?

The latter result is a fairly serious constraint on our plgrid
function for i686 hardware.  So I am hoping for the former result
since that simply means the gcc option -mieee-fp is no longer required
to get this NaN test to work correctly on i686 hardware.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] libieee.a is no more

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

Apparently glibc is dropping libieee.a in the next release.  In Fedora
Rawhide, -mieee-fp on i686 results in:

/usr/bin/ld: Cannot find -lieee

Dropping -mieee-fp from csiro.cmake fixes it for me.  Also works with glibc
2.25.  Not sure about older ones.

diff -up plplot-5.12.0/cmake/modules/csiro.cmake.ieee
plplot-5.12.0/cmake/modules/csiro.cmake
--- plplot-5.12.0/cmake/modules/csiro.cmake.ieee        2017-01-28
18:50:35.000000000 -0700
+++ plplot-5.12.0/cmake/modules/csiro.cmake     2017-12-12 15:05:56.964587720
-0700
@@ -27,17 +27,13 @@ option(WITH_CSA "Enable use of the csa l
 # expanded to a lot more cases as we gain platform experience.
 set(NAN_CFLAGS ${CMAKE_C_FLAGS})
 if(PL_HAVE_QHULL OR WITH_CSA)
-  if(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86")
-    set(NAN_CFLAGS "${NAN_CFLAGS} -mieee-fp")
-  else(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86")
-    if(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
-      if(CMAKE_C_COMPILER MATCHES "gcc")
-        set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
-      else(CMAKE_C_COMPILER MATCHES "gcc")
-        set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
-      endif(CMAKE_C_COMPILER MATCHES "gcc")
-    endif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
-  endif(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86")
+  if(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
+    if(CMAKE_C_COMPILER MATCHES "gcc")
+      set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
+    else(CMAKE_C_COMPILER MATCHES "gcc")
+      set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
+    endif(CMAKE_C_COMPILER MATCHES "gcc")
+  endif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
   if(NOT DEFINED NaNAwareCCompiler)
     message(STATUS "Check for NaN awareness in C compiler")
     try_run(NaNAwareCCompiler COMPILE_RESULT

Fedora doesn't build for alpha, so no idea there.



-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Plplot-devel] We now have a clean PostScript difference report!

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

On 2017-12-09 11:18-0800 Alan W. Irwin wrote:

> I am happy to report I have just solved the long-standing
> inconsistency between OCaml example 16 results and the
> results from other languages.  See commit 35eafc1 for details.
>
> This breakthrough means that an absolutely perfect PostScript
> difference report is finally within our grasp again after ~6 years
> without that.  "All" that needs to be done is to implement the color
> bar parts of example 33 in OCaml. I will take responsibility for that
> implementation.

DONE.  See
<https://sourceforge.net/p/plplot/plplot/ci/a7be76715300e829523be309c64d99b1b28c1bcc/>
and the updated version of README.release for the details.

In sum, we now have a clean PostScript difference report for the first
time in many years (i.e., the standard examples written in all our
supported languages give the same PostScript results for all those
languages), and I am happy I was able to learn enough about our OCaml
binding implementation and the language itself to fix this
long-standing 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
__________________________

[Plplot-devel] Long-standing OCaml example 16 inconsistency solved

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

I am happy to report I have just solved the long-standing
inconsistency between OCaml example 16 results and the
results from other languages.  See commit 35eafc1 for details.

This breakthrough means that an absolutely perfect PostScript
difference report is finally within our grasp again after ~6 years
without that.  "All" that needs to be done is to implement the color
bar parts of example 33 in OCaml. I will take responsibility for that
implementation.

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] Patch for OCaml 4.06

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

On 2017-11-20 09:02-0700 Orion Poplawski wrote:

> Fedora patch to fix build with OCaml 4.0.6.

Hi Orion:

I assume you meant 4.06.0 (see the list of releases at
<https://ocaml.org/releases/>).

Thanks (!) for your fix for this backwards-incompatible change to
OCaml.  However, I am going to delay applying your fix because it
breaks my build of examples/ocaml/x20.ml for my (Debian Jessie)
ocaml-4.01.0.

The problem (according to
<https://stackoverflow.com/questions/30887196/install-ocaml-bytes-module-on-debian>)
is the Bytes module (used by your patch) was first introduced in OCaml 4.02.0
so it is not avaliable for Debian Jessie.

I have put on my PLplot ToDo list (which I review for each PLplot
release) to upgrade from my current Debian Jessie to Debian Stretch =
Stable, apply your patch, and put in the release notes that we only
support OCaml 4.02.3 (the version available for Debian Stretch) or
higher.  I plan to do that Debian update soon, and if all goes well
with that update your fix should be part of the next release of PLplot
(tentatively scheduled for early 2018).

Best wishes,

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Patch for OCaml 4.06

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

Fedora patch to fix build with OCaml 4.0.6.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Plplot-devel] The Contracts.PLplot test of CMake has now been implemented and works well for me

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

Below I have forwarded a message I sent to the cmake developers list
that summarizes the Contracts.PLplot test that has been recently implemented
by Brad King and that works well for me.

If you like that idea for helping out with both CMake and PLplot
testing using an automatic procedure, I strongly urge you to set up this test.

This test is configured as follows:

1. Follow the directions at
<https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst>.

which largely consist of

git clone https://gitlab.kitware.com/cmake/dashboard-scripts.git
CMakeScripts
cd CMakeScripts

2. The cmake_common.cmake script that appears in that directory
contains comments at the top with instructions to set up a testing
client. As it instructs, create a CTest script with local settings and
include cmake_common.cmake. I called that script my_dashboard.cmake,
and I attach it as a prototype for how to configure the
Contracts.PLplot for CMake. (See
<https://cmake.org/Wiki/CMake_Scripting_Of_CTest> for additional
documentation concerning how to set up CTest scripts.)

Note, you are free to specify any cmake option for the PLplot
configuration in my_dashboard.cmake.  I have chosen -DBUILD_TEST=ON
(to add builds of all the compiled examples to the usual build),
-DBUILD_DOC=ON (to add a build of the DocBook-generated
documentation). and -DBUILD_DOX_DOC=ON (to add a build of the
Doxygen-generated documentation).  I have not specified
BUILD_SHARED_LIBS or ENABLE_DYNDRIVERS so the default (ON) values are
used for those corresponding to shared libraries/dynamic devices.  But
obviously you can choose not to build anything extra and you could
also specify either -DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=OFF or
-DBUILD_SHARED_LIBS=OFF -DENABLE_DYNDRIVERS=OFF to test our other two
major build configurations (shared libraries/nondynamic devices or
static libraries/nondynamic devices). I have also chosen a particular
fixed PLplot commit to have complete testing consistency for the
latest staged version of CMake (at least until I change that specified
PLplot commit again). But you are also free to specify a non-fixed
PLplot commit (such as HEAD which should test whether the latest master
branch version of PLplot always builds on your platform with the
latest staged version of CMake).

3. Once you have created your own version of the my_dashboard.cmake
script you can test it as follows.

a. Temporarily replace
set(dashboard_model Nightly)

with

set(dashboard_model Experimental)

in the script.

b. Run the script, e.g., with

ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out

This should take something like half an hour (at least if you are
using ccache) to build the staged
branch version of CMake, run all ctests for that version including
the Contracts.PLplot test, and report the results of all those tests as an Experimental
dashboard at https://open.cdash.org/index.php?project=CMake.

4. Once that test of the Experimental mode works, then change the
script again to replace

set(dashboard_model Experimental)

with

set(dashboard_model Nightly)

and follow the directions at

<https://cmake.org/Wiki/CMake_Scripting_Of_CTest>

for setting up Cron/Scheduler to run the
script once per day.

For those with access to crontab, here is how I configured that
using the

crontab -e -u software

command (where software is the name of the login account where I run
all these tests).

# Set important environment variables.
# Set the shell to bash because there are bashisms below.
SHELL=/bin/bash
# PATH must include ccache (for build speed) and my default build of
cmake (so I # can run ctest from that version).  The rest of PATH is standard.
PATH=/usr/lib/ccache:/home/software/cmake/install/bin:~/bin:/usr/bin/:/bin

# Using env below to set DISPLAY to what is appropiate for the software account on raven
# allows the DISPLAY-dependent part of the PLplot configuration to work for
# that contract test for PLplot.

# Set time of command and what command is actually run using the
# following format:
# m h  dom mon dow   command
32  04   *   *   * env DISPLAY=localhost:10.0 ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ~/cmake/Dashboards/crontab_ctest.log

which means that script is automatically executed at 4:32 local time
each day, but obviously you can choose any time of the day that is
convenient for you.

Once automatic Nightly runs of your Ctest my_dashboard.cmake script
are implemented, then that script collects results as a Nightly
dashboard which you should be able to see for each day in the Nightly
section of <https://open.cdash.org/index.php?project=CMake>.

For the sake of encouraging widespread testing of PLplot, I hope most
of you become interested in testing CMake with a build of PLplot in
this automated way on all the platforms of interest to you.  If you
have any further questions about configuring a Contracts.PLplot test
of CMake, don't hesitate to get in touch with me.

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
__________________________

---------- Forwarded message ----------
Date: Thu, 9 Nov 2017 21:40:36 -0800 (PST)
From: Alan W. Irwin <ir...@be...>
To: Brad King <bra...@ki...>, Ben Boeckel <ben...@ki...>,
     cma...@cm...
Subject: Re: [cmake-developers] PLplot contract test

On 2017-11-08 18:00-0800 Alan W. Irwin wrote:

[...]
> Changing topics back to the Nightly case where the job is started in a
> crontab environment rather than on the normal desktop command line as
> above, further research indicates it is possible to set DISPLAY for
> such environments (assuming that DISPLAY exists at the time the
> crontab job fires as is typical for my case).  So I am going to try
> that to see if that change plus the above setting of XAUTHORITY solves
> the Nightly issue as well.

Thanks to that crontab change to define the DISPLAY environment
variable, all is now well with the Nightly case, see
<https://open.cdash.org/testDetails.php?test=598968882&build=5135648>.

So that appears to be the end of the configuration issues with the
Contracts.PLplot test, and my thanks to Brad for implementing this
test in the first place, and both Brad and Ben for some key help with
my configuration of this test.

So for others here that might be interested, Contracts.PLplot tests a
build of the stage/master/nightly/latest branch of CMake by using
ExternalProject_Add to git checkout a specified version of PLplot and to 
configure, build, and install that version with user control of the
PLplot version selected for the test and the CMake options used to
build PLplot.  So this test is good from the PLplot perspective
because it makes it more difficult for some new CMake development to
cause PLplot developers problems without us knowing it long in advance
of CMake releases.  And it is also good from the CMake testing
perspective since it is a test that exercises a lot of different CMake
functionality in a realistic way (i.e., as used in a rather complex
build system, warts and all).  Additional notes are (1) because of the
relatively small size of the PLplot project (despite its build-system
complexity) this test adds less than ~30 per cent to the overall cost
of building and testing CMake, and (2) this test should work on
essentially all platforms (the build of PLplot is known to work on at
least Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2, and MSVC). So if
anyone else is interested in trying this test on their favorite
platform(s), feel free to contact me for help with configuring it and
overcoming any PLplot build failures in the unlikely event of you
encountering those.

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
__________________________
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

On 2017-11-08 07:49-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, November 07, 2017 11:20 PM
>>
>> Hi Arjen:
>>
>> To clean up some preliminary stuff, please don't set GNAT_LIB unless absolutely
>> necessary.  Specifying that variable is a workaround that bypasses all testing of the
>> find_library command (see
>> <https://cmake.org/cmake/help/v3.10/command/find_library.html> for why that is so.
>
> Oh, that was a stupid mistake - too many little tasks clogging my head and thus I simply followed the advice from the error message: an unaided "comprehensive_test_ada.sh" does not find the Gnat library.
>

> With CMAKE_LIBRARY_PATH set to the right directory the test does
succeed but fails in the same way as before. So the CMake build script
finds the proper library, but there is something going on with the
library itself.

I agree with that general conclusion based on what I see in your report
tarball for this shared case.  But I would add that the fundamental
run time error you are seeing is

raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION

for the hello.exe that is built from the installed example source
code.  And for me any error message that mentions "access violation"
in any way likely means there is a memory management issue.  So I
think the most obvious next step is to run a memory management
analysis tool like valgrind (although not that exact tool since it
apparently does not work on Windows platforms) on the hello.exe
executables that are built in the build tree and the install tree.

> I have attached two tarballs: one with only the CMAKE_LIBRARY_PATH
set and one excluding the shared build, leaving the static case. This
fails on account of duplicate symbols again.

I also looked at that additional report tarball, and the build system has done
everything in the static case that I thought it should do, i.e.,
always link with import form of the gnat library regardless of whether
the test_ada Ada library is built as a shared library (which builds
without issues from your other report tarball) or as a static library
(this case which you have just showed obviously does not build correctly).  So
please follow up by using GNAT_LIB in this emergency situation for the
static case to specify libgnat.a, and let me know those results
to help guide me toward the correct find_library configuration
for the normal case where CMAKE_LIBRARY_PATH is specified on Cygwin.

> No time right now to look into your other suggestions.

I promise to be patient.  And in any case I think we are headed toward
preparing a bug report for the Ada components of the gcc toolchain on
Cygwin.  So patience is needed in any case because that bug (once we
isolate it for the simplest case possible and prepare the bug report)
is likely going to take some time for the Cygwin gcc package
maintainers or possibly even the upstream Ada compiler developers to
fix.

Nevertheless, even though I think we are likely stuck in a long
process, I would like to continue moving forward with that process
without too many inefficient long gaps.  So the next chance you have
to work on PLplot I would appreciate it if you followed up with this
issue in the two ways I have suggested above.

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, November 07, 2017 11:20 PM
>
> Hi Arjen:
>
> To clean up some preliminary stuff, please don't set GNAT_LIB unless absolutely
> necessary.  Specifying that variable is a workaround that bypasses all testing of the
> find_library command (see
> <https://cmake.org/cmake/help/v3.10/command/find_library.html> for why that is so.

Oh, that was a stupid mistake - too many little tasks clogging my head and thus I simply followed the advice from the error message: an unaided "comprehensive_test_ada.sh" does not find the Gnat library.

With CMAKE_LIBRARY_PATH set to the right directory the test does succeed but fails in the same way as before. So the CMake build script finds the proper library, but there is something going on with the library itself.

I have attached two tarballs: one with only the CMAKE_LIBRARY_PATH set and one excluding the shared build, leaving the static case. This fails on account of duplicate symbols again.

No time right now to look into your other suggestions.

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

On 2017-11-07 12:35-0000 Arjen Markus wrote:

> Hi Alan,

> I got an odd error while running the comprehensive test script for
Ada - see the attached tarball. The good news is that it was a crash
in running the program, not an interruption of the build process.

Hi Arjen:

To clean up some preliminary stuff, please don't set GNAT_LIB unless
absolutely necessary.  Specifying that variable is a workaround that
bypasses all testing of the find_library command (see
<https://cmake.org/cmake/help/v3.10/command/find_library.html> for why
that is so.  For example, it completely bypasses the changed
find_library command in my patch.  Instead, I would prefer you to set
the environment variable CMAKE_LIBRARY_PATH (if necessary) to the
directory location where the gnat import library can be found.  That
method then tests whether find_library works properly (which is part
of the point of these tests).

Furthermore, the run-time error you found was for the shared case so
please follow up by testing whether that also occurs for the static case using

cmake/test_ada/scripts/comprehensive_test.sh --do_shared no

(that "--do_shared no" option skips over the shared part of the test
as documented if you run cmake/test_ada/scripts/comprehensive_test.sh
--help).

Moving on to the run-time error you found for the shared case, i.e.,

raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION

, that issue was just raised for the installed examples case
and not the build-tree case which is an interesting result.

So from your report tarball I looked carefully at how the two
different cases were built, i.e.,

# Build tree
/usr/bin/gnatmake.exe  -Wl,--enable-auto-import "-aI/cygdrive/d/plplot-svn/plplot-git/cmake/test_ada/src_executable" "-aI/cygdrive/d/plplot-svn/plplot-git/cmake/test_ada/src_lib" "-aL/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/build_tree/src_lib/CMakeFiles/hello_1.dir" hello.adb -cargs  -largs ../dll/libhello.dll.a 
# Build tree for the installed example
/usr/bin/gnatmake.exe  -Wl,--enable-auto-import "-aI/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/share/test_ada/examples/ada" "-aI/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/share/ada/adainclude/test_ada" "-aL/cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/lib/ada/adalib/test_ada" hello.adb -cargs  -largs /cygdrive/d/plplot-svn/comprehensive_test_ada_disposeable/shared/noninteractive/install_tree/lib/libhello.dll.a

My experience is gnatmake is extraordinarily picky about its builds
and will error out if the slightest thing is wrong.  But all was well
in that regard with your two builds.  Furthermore, visual inspection
of the two separate commands above indicates the two different
versions refer respectively to build-tree and installed examples build
tree locations (as expected).  In addition, Ada libraries are really
straightforward to build and install (build the objects from *.adb
source with no special gcc options other than -fPIC, collect the
generated object files in a library and keep track of the
corresponding Ada *.adb source files and generated *.ali files and
install the library, and its corresponding *.ada and *.ali files.) If
that installation were incomplete in the slightest way, the above
second gnatmake command would have errored out. So I really think all
is well with the install.

Thus, the only thing I can think of to follow up with this error is
the above PROGRAM_ERROR appears to be referring to a memory management
issue.  Often those are silent errors (especially on Windows) so by
accident the given memory management issue might be silent for the
build tree but not for the installed examples build tree.  So I looked
for that sort of issue here (Debian Jessie) after a run of

cmake/test_ada/scripts/comprehensive_test.sh

as follows:

# change to comprehensive test prefix directory
software@raven> cd ../comprehensive_test_ada_disposeable
# valgrind test hello executables in both the build and installed
# examples build directories.
software@raven> valgrind shared/noninteractive/build_tree/src_executable/hello
==26389== Memcheck, a memory error detector
==26389== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26389== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==26389== Command: shared/noninteractive/build_tree/src_executable/hello
==26389== 
==26389== 
==26389== HEAP SUMMARY:
==26389==     in use at exit: 0 bytes in 0 blocks
==26389==   total heap usage: 4 allocs, 4 frees, 740 bytes allocated
==26389== 
==26389== All heap blocks were freed -- no leaks are possible
==26389== 
==26389== For counts of detected and suppressed errors, rerun with: -v
==26389== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

software@raven> valgrind shared/noninteractive/install_build_tree/ada/hello
==26390== Memcheck, a memory error detector
==26390== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26390== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==26390== Command: shared/noninteractive/install_build_tree/ada/hello
==26390== 
==26390== 
==26390== HEAP SUMMARY:
==26390==     in use at exit: 0 bytes in 0 blocks
==26390==   total heap usage: 4 allocs, 4 frees, 740 bytes allocated
==26390== 
==26390== All heap blocks were freed -- no leaks are possible
==26390== 
==26390== For counts of detected and suppressed errors, rerun with: -v
==26390== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As you can see, there are perfect memory management results on Linux
for both these cases.

Therefore, since test_ada is so simple, I am beginning to lean toward
an explanation that there is something fundamentally wrong with the
Ada component of the gcc tool chain on Cygwin.  To test that
hypothesis further is there an equivalent to valgrind (see
<https://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows>
for some ideas) that you could run?  And if you do find a memory
management issue on Cygwin that way, could you also try the same tool
on the simplest shared gnatmake example I asked you to build the other
day?  That would be the first step in preparing a bug report to the
Cygwin mailing list concerning the Ada component of the gcc tool chain
based not on test_ada but on that even simpler shared gnatmake
example.

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

Hi Alan,



I got an odd error while running the comprehensive test script for Ada - see the attached tarball. The good news is that it was a crash in running the program, not an interruption of the build process.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, November 07, 2017 11:16 AM
...

>
> Once you have complete success with the test_ada project, than I will want to
> make a similar change to the PLplot project, but I haven't done that yet.
>
As indicated above, only partial success.

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, November 07, 2017 11:16 AM
>
...

> It appears from your last comment that you have been testing the plplot project.
> Those do sound like promising results, but they are premature.
>
> The present patch was limited to just the test_ada project. So to test that patch you
> need to follow my test instructions above. Likely you will have to set
> CMAKE_LIBRARY_PATH to the location of the import library to get that
> comprehensive test (of test_ada) to work.
>
> Once you have complete success with the test_ada project, than I will want to
> make a similar change to the PLplot project, but I haven't done that yet.
>
Ah, I misread your previous mail. For some reason git refused to apply the patch, but it was simple enough to do manually. I thought I had seen a message about another file, so that perpetuated my mistake ;). I will try the test_ada subproject later today.

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

On 2017-11-07 08:34-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Friday, November 03, 2017 8:37 PM
>> When you get a chance please commit this change on a local topic branch using
>> "git am" and try it out on Cygwin using
>>
>> cmake/test_ada/scripts/comprehensive_test.sh
>>
> I applied the patch and got some encouraging results:
>
> - With -DCMAKE_LIBRARY_PATH=/path/to/ada-libraries I go the same errors as before
>

> - With -DGNAT_LIB=/path/and/name/of/import-library I got - finally -
working Ada examples. Both the standard and traditional versions work
fine.

It appears from your last comment that you have been testing the plplot
project.  Those do sound like promising results, but they are premature.

The present patch was limited to just the test_ada project. So to test
that patch you need to follow my test instructions above. Likely you
will have to set CMAKE_LIBRARY_PATH to the location of the import
library to get that comprehensive test (of test_ada) to work.

Once you have complete success with the test_ada project, than
I will want to make a similar change to the PLplot project, but
I haven't done that yet.

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, November 03, 2017 8:37 PM
> When you get a chance please commit this change on a local topic branch using
> "git am" and try it out on Cygwin using
>
> cmake/test_ada/scripts/comprehensive_test.sh
>
I applied the patch and got some encouraging results:

- With -DCMAKE_LIBRARY_PATH=/path/to/ada-libraries I go the same errors as before

- With -DGNAT_LIB=/path/and/name/of/import-library I got - finally - working Ada examples. Both the standard and traditional versions work fine.

(I did notice something odd about example x03: with both the C and Ada examples using the wingcc and X Window the window is empty. The PostScript file shows only a partial plot - labels around the radial diagram. I have attached it for further discussion. Very strange - other examples work fine)

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

On 2017-11-03 11:52-0000 Arjen Markus wrote:

> Yes, I saw it [new Ada packaging for Cygwin] and I have updated my
installation.

Good.

> I see the import library now, but my very preliminary
tests (test_ada and a simple build) have failed so far:

> - test_ada does not produce an executable - see the tarball (sorry,
output to the screen is missing, but there was nothing much to see
anyway).

> - a simple build finds the static library and then the duplicate
symbols problem is back.

> I guess PLplot needs to be told to use the import library before
trying the static one. I have not had time yet to do the manual steps
that you suggest.

On Linux I have tried the experiment of forcing the shared
or static versions of gnat lib as follows:

-DGNAT_LIB=/usr/lib/gcc/x86_64-linux-gnu/4.9/adalib/libgnat.so

or

-DGNAT_LIB=/usr/lib/gcc/x86_64-linux-gnu/4.9/adalib/libgnat.a

The shared version (equivalent to the import library version for
you) works both with -DBUILD_SHARED_LIBS=ON or OFF.  (N.B.
-DBUILD_SHARED_LIBS affects only how our Ada library is built
and does not affect how that library and our 
Ada executables are linked to external libraries such as gnat.)

The static version of the gnat library only works for the
-DBUILD_SHARED_LIB=OFF case. (The Linux issue for the
-DBUILD_SHARED_LIB=ON case is libgnat.a was built without the -fPIC
flag, but I presume there are similar compilation flag issues when
attempting to use libgnat.a for -DBUILD_SHARED_LIB=ON on Cygwin that
cause the duplicate symbols issue you see there.)

So I agree with you we should likely be fine if we always find the shared version of the gnat
library on Linux and the import version of the gnat library on Cygwin (and
other Windows platforms).

That happens automatically (if not forcing like above) in the Linux
case since CMake always prefers to find the shared version of
libraries if given a choice with the same basename ("gnat" above with
no version number).  So that is why comprehensive testing of test_ada
has "just worked" on that platform.

But Windows has no standard naming conventions
for libraries so you have to identify independently what filename
corresponds to the import library (in the Cygwin case that filename is
libgnat-6.dll.a, but who knows, for example, what it might be for
MinGW-w64/MSYS2 or some arbitrary build of the gnu tool chain on
Windows) so we have to be quite specific for what library name we want
to find in the Windows case in order to guarantee we have the import
form of the gnat library.

The attached commit makes this change for the Cygwin case (and fills
in something generic for the non-Cygwin Windows case which will likely
need to be corrected in the future for the MinGW-w64/MSYS2 case).

When you get a chance please commit this change on a local topic branch using "git am" and
try it out on Cygwin using

cmake/test_ada/scripts/comprehensive_test.sh

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, November 02, 2017 9:13 PM
> To: Arjen Markus; PLplot development list
> Subject: Re: Possible fix for the test_ada project on Cygwin (NO LONGER
> RELEVANT)
>
...
>
> Hi Arjen:
>
> As you are probably aware, thanks to the efforts of Marco to bring this Ada
> packaging issue to the Cygwin mailing list and Jon to implement the packaging fix,
> my workaround patch is no longer relevant.  See <https://cygwin.com/ml/cygwin-
> announce/2017-11/msg00007.html> where the latest version of the gcc collection of
> compilers now properly includes the gnat import library.  I followed up with a gnat-
> 6.dll search on <http://cygwin.com/cgi-bin2/package-grep.cgi> and the
> gcc-ada-6.4.0-2 package includes
>

Yes, I saw it and I have updated my installation. I see the import library now, but my very preliminary tests (test_ada and a simple build) have failed so far:

- test_ada does not produce an executable - see the tarball (sorry, output to the screen is missing, but there was nothing much to see anyway).

- a simple build finds the static library and then the duplicate symbols problem is back.


I guess PLplot needs to be told to use the import library before trying the static one. I have not had time yet to do the manual steps that you suggest.

>
> Note how the import library form is much larger than the dll form and therefore
> completely distinct from it (as expected).
>
> So the next chance you have to work on PLplot, please upgrade your Cygwin
> installation to this latest (6.4.0-2) gcc collection of compilers, and confirm the
> following tests now work (note the change from the above for the shared one which
> is a simpler and better form of the test):
>

Not done yet ...

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] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

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

On 2017-10-30 11:33-0700 Alan W. Irwin wrote:

> Hi Arjen (returning this discussion to the plplot-devel list):
>
> Thanks for sending me (off list) the output from the
>
> gnatmake -v hello.adb -cargs -fPIC -bargs -shared -largs -v -shared
>
> gnatmake -v hello.adb -bargs -static -largs -v -static
>
> commands on Cygwin.  Based on that information I have come up with the
> attached local commit (prepared with "git format-patch") to workaround
> (just for the test_ada project for now) the Cygwin Ada packaging issue
> revealed by the first of the above commands.
>
> Could you let me know if that commit works for you,
> i.e., once it is locally applied with "git am" does
>
> cmake/test_ada/scripts/comprehensive_test.sh
>
> finally work for you on Cygwin?  Also, win or lose, I would like to
> see the report tarball from this test.

Hi Arjen:

As you are probably aware, thanks to the efforts of Marco to bring
this Ada packaging issue to the Cygwin mailing list and Jon
to implement the packaging fix, my workaround patch
is no longer relevant.  See
<https://cygwin.com/ml/cygwin-announce/2017-11/msg00007.html> where
the latest version of the gcc collection of compilers now properly
includes the gnat import library.  I followed up with a gnat-6.dll
search on <http://cygwin.com/cgi-bin2/package-grep.cgi> and the
gcc-ada-6.4.0-2 package includes

2017-10-31 04:09     9473456 /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat-6.dll.a
2017-10-31 04:09    16423982 /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a

and the libgnat6-6.4.0-2 package includes

2017-10-31 04:11     2984467 /usr/bin/cyggnat-6.dll

Note how the import library form is much larger than the dll form and
therefore completely distinct from it (as expected).

So the next chance you have to work on PLplot, please upgrade your
Cygwin installation to this latest (6.4.0-2) gcc collection of
compilers, and confirm the following tests now work (note the change
from the above for the shared one which is a simpler and better form
of the test):

# Create the simple Ada test code (if you have not done so before)
cat > hello.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
    Put_Line ("Hello WORLD!");
end Hello;

# shared case
# remove results of all previous build attempts (if any)
rm -f hello hello.ali hello.o
gnatmake -v hello.adb -bargs -shared -largs -v
# test shared case
./hello

# static case
# remove results of all previous build attempts (if any)
rm -f hello hello.ali hello.o
gnatmake -v hello.adb -bargs -static -largs -v
# test static case
./hello

I find these tests work here (Debian Jessie with gcc 4.9.2) without
issues, and I urge anyone here who wants to test their Ada and gnat
installation to try these simple tests first.

Assuming the above simple gnatmake tests work on Cygwin for the
6.4.0-2 case, please follow up by running
cmake/test_ada/scripts/comprehensive_test.sh for our current master
branch without my patch (i.e., nothing locally changed in
cmake/test_ada).

I am pretty sure the net result when linking the test_ada library will
be the import form of the gnat library will be found and linked in the
shared case and the static form of the gnat library will be found and
linked in the static case, and the test will "just work".  However, if
your report tarball shows any remaining issues for the test_ada
comprehensive test, I will fix them.

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] Possible fix for the test_ada project on Cygwin

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

Hi Alan,



I will look into this, but it may be a few days before I have the opportunity to sit down for this. In the meantime, I see there is activity on the Cygwin mailing list regarding the issue. So the maintainers are aware of the problem and are working on it.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, October 30, 2017 7:33 PM
> To: Arjen Markus; PLplot development list
> Subject: Possible fix for the test_ada project on Cygwin
>
> Hi Arjen (returning this discussion to the plplot-devel list):
>
> Thanks for sending me (off list) the output from the
>
> gnatmake -v hello.adb -cargs -fPIC -bargs -shared -largs -v -shared
>
> gnatmake -v hello.adb -bargs -static -largs -v -static
>
> commands on Cygwin.  Based on that information I have come up with the attached
> local commit (prepared with "git format-patch") to workaround (just for the test_ada
> project for now) the Cygwin Ada packaging issue revealed by the first of the above
> commands.
>
> Could you let me know if that commit works for you, i.e., once it is locally applied
> with "git am" does
>
> cmake/test_ada/scripts/comprehensive_test.sh
>
> finally work for you on Cygwin?  Also, win or lose, I would like to see the report
> tarball from this test.
>
> 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.

[Plplot-devel] Possible fix for the test_ada project on Cygwin

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

Hi Arjen (returning this discussion to the plplot-devel list):

Thanks for sending me (off list) the output from the

gnatmake -v hello.adb -cargs -fPIC -bargs -shared -largs -v -shared

gnatmake -v hello.adb -bargs -static -largs -v -static

commands on Cygwin.  Based on that information I have come up with the
attached local commit (prepared with "git format-patch") to workaround
(just for the test_ada project for now) the Cygwin Ada packaging issue
revealed by the first of the above commands.

Could you let me know if that commit works for you,
i.e., once it is locally applied with "git am" does

cmake/test_ada/scripts/comprehensive_test.sh

finally work for you on Cygwin?  Also, win or lose, I would like to
see the report tarball from this test.

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] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32 (NOW FIXED)

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, October 11, 2017 4:18 AM
...

>
> @Those here with access to Windows:
>
> Accordingly I have now replaced use of the WIN32 and __WIN32__ macros with
> the _WIN32 macro throughout our C and C++ source code (commit 14ecc4b).  This
> is an intrusive change so I would appreciate tests of it on all Windows compilers
> and Windows platforms (e.g., MSVC, Cygwin, and MinGW-w64/MSYS2) accessible
> to you.
>
I have tested the new code on Cygwin 64 bits, MinGW-w64/MSYS2 (also 64 bits) and Windows/MSVC (also 64 bits) and found that all is working fine. I stress the 64-bits aspect, because the macros originated on 32-bits systems and were propagated to 64-bits. Perhaps we should include the 32-bits variant of the above platforms in the testing too.

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.

[Plplot-devel] CMake-3.10.0-rc2 yields good comprehensive test results for PLplot

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

I just completed a comprehensive test of PLplot on Linux (Debian
Jessie) using a cmake version that I built myself from the
CMake-3.10.0-rc2 source code using the bootstrap method.  The result
was a complete success for the three different PLplot build systems
(CMake-based build systems for the core build and installed examples,
and a CMake-configured traditional [Makefile + pkg-config] build
system for the installed examples) and the 3 major PLplot build
configurations (shared libraries/dynamic devices, shared
libaries/nondynamic devices, and static libraries/nondynamic devices).
So from the PLplot perspective, CMake-3.10.x is looking quite
promising. For further details of this comprehensive test, see the
"Tested by" stanza of the git log for PLplot commit 6906798
<https://sourceforge.net/p/plplot/plplot/ci/69067983c65013058cfbe4cf047f0817f1933d37/>).

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] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32 (NOW FIXED)

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

On 2017-10-10 06:52-0400 Jim Dishaw wrote:

[....]
> I read the MSDN Documentation as well as the Intel, MinGW, and GNU compiler documentation.
>
> The WIN32 should not be used and appears to be an older convention   The MSDN and Intel documentation define _WIN32 and _WIN64. MinGW appears to be following MSDN, which makes sense.
>
> Moving away from WIN32 will break builds on older platforms that we no longer support, but I don’t think that is a problem.
>
> I would stay away from __WIN32__ as that is not in the MSDN documentation.

To Arjen and Jim:

@Arjen:

Thanks for running that quick check (in a different post than the
above) on Cygwin which gave the expected result, but it is always good
to be sure.

@Jim:

Thanks very much for that clear advice above. I agree with you the
proposed change (to move strictly to _WIN32) will break builds for
older versions of compilers that we don't support in any case.  But
with modern versions of Intel, MSVC, gcc, and clang compilers all
providing the _WIN32 macro for their pure native Windows builds, I
would frankly be amazed if modern versions of much less popular
compilers (e.g., Borland and Watcom) did not provide that macro as
well.  So I have decided to go ahead with this proposed change.

@Those here with access to Windows:

Accordingly I have now replaced use of the WIN32 and __WIN32__ macros
with the _WIN32 macro throughout our C and C++ source code (commit
14ecc4b).  This is an intrusive change so I would appreciate tests of
it on all Windows compilers and Windows platforms (e.g., MSVC, Cygwin,
and MinGW-w64/MSYS2) accessible to you.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, October 10, 2017 1:36 PM
>
> My understanding is non-POSIX Cygwin is a thing of the past, i.e., you have the
> POSIX version where no variant of WIN32 is #defined.  But to be absolutely sure
> on this point, write a simple programme which includes the
> following:
>
> #if defined(WIN32) || defined(_WIN32) || defined (__WIN32__) #error Cygwin
> defines at least one of the variants of the WIN32 macro #endif
>


That was easily tested - just for good measure (and to be sure something was happening) I added an #else case. Compiling that gave me the assurance that none of these macros is defined by the gcc compiler on Cygwin.

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] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

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

Hi Arjen:

I agree its a dated table.  So, for example, it is possible
MinGW-w64 later severely changed course from the documentation
of the classical MinGW in this table.  However, if we changed
to _WIN32, and MinGW-w64 did not #define that
then your comprehensive test of MinGW-w64/MSYS2
would show problems immediately.  But I don't think
that is going to happen (i.e., I don't believe MinGW-w64
took a different course than MinGW in what WIN32-related
macros they #define).

More below.
On 2017-10-10 07:20-0000 Arjen Markus wrote:

> Hi Alan,

> I have had a look at the two discussions Alaric and you mention, and
I agree that the best choice seems to be _WIN32 to indicate the
Windows platform. I hesitate, however, to be absolutely sure, on the
following grounds:

> - The tip on detecting the operating systems mentions that there is
no 64-bits Cygwin system, but that was the case back in 2012. I have
been using Cygwin 64-bits for a couple of years now.

> - There is also mention of Cygwin in a POSIX and in a non-POSIX
variant. I have no clue as to how to determine which one I am working
with or how to specify that at install time.

My understanding is non-POSIX Cygwin is a thing of the past, i.e., you have the POSIX
version where no variant of WIN32 is #defined.  But to be absolutely
sure on this point, write a simple programme which includes the
following:

#if defined(WIN32) || defined(_WIN32) || defined (__WIN32__)
#error Cygwin defines at least one of the variants of the WIN32 macro
#endif

> - Also the table "Windows, Cygwin (non-POSIX), and MinGW" has
columns for the "Windows target" and the "MinGW target". It is unclear
to me what they mean by that.

I think the following note for the table explains it:

"Based on command-line options, the Clang/LLVM and GCC compilers can
build Windows applications or POSIX applications that run under
Windows using POSIX compatibility libraries."

I am virtually positive they are referring to the same distinction
used on MinGW-w64/MSYS2 between 
the "mingw" and "msys" repositories where the
first is native Windows while the second requires POSIX
compatibility libraries (the MSYS2 dll) in order to run under Windows.

In contrast, for modern Cygwin you build applications and libraries
that require the cygwin.dll compatibility library in order to run on
Windows.

> - Furthermore: is "MinGW" the old-style MinGW or the new one,
MinGW-w64/MSYS2? From the date of the post, I would say the former.

I agree.  But see my initial note above.

> All that does not mean that we should not consistently use _WIN32,
but perhaps some care is to be taken. The page
https://msdn.microsoft.com/en-us/library/b0084kay.aspx indicates that
Visual C++ does define _WIN32 for both the 32-bits and 64-bits
platforms. On the other hand, this page from the GNU C compiler
documentation says that macros whose name starts with two (!)
underscores are to be considered reserved and does not mention the
one-underscore macros as being special (only historical):
https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/System-specific-Predefined-Macros.html#System-specific%20Predefined%20Macros.

Nevertheless, everything I have read indicates non-Cygwin gcc on Windows does
#define _WIN32.

> I guess that only adds to the confusion :(.

Well, if we make a mistake here, it is easily rectified (assuming
testing on all 3 of your platforms).

As you can likely tell, I feel we should probably just go ahead
with this change, and just make sure it is well tested.  But before
doing that I will wait to see your response to my comments
above (as well as your results from the simple Cygwin test
I proposed above).

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] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

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

Hi Alan,



I have had a look at the two discussions Alaric and you mention, and I agree that the best choice seems to be _WIN32 to indicate the Windows platform. I hesitate, however, to be absolutely sure, on the following grounds:

-        The tip on detecting the operating systems mentions that there is no 64-bits Cygwin system, but that was the case back in 2012. I have been using Cygwin 64-bits for a couple of years now.

-        There is also mention of Cygwin in a POSIX and in a non-POSIX variant. I have no clue as to how to determine which one I am working with or how to specify that at install time.

-        Also the table "Windows, Cygwin (non-POSIX), and MinGW" has columns for the "Windows target" and the "MinGW target". It is unclear to me what they mean by that.

-        Furthermore: is "MinGW" the old-style MinGW or the new one, MinGW-w64/MSYS2? From the date of the post, I would say the former.



All that does not mean that we should not consistently use _WIN32, but perhaps some care is to be taken. The page https://msdn.microsoft.com/en-us/library/b0084kay.aspx indicates that Visual C++ does define _WIN32 for both the 32-bits and 64-bits platforms. On the other hand, this page from the GNU C compiler documentation says that macros whose name starts with two (!) underscores are to be considered reserved and does not mention the one-underscore macros as being special (only historical): https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/System-specific-Predefined-Macros.html#System-specific%20Predefined%20Macros.



I guess that only adds to the confusion :(.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, October 09, 2017 8:02 PM
> To: Arjen Markus; PLplot development list
> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
>
> Hi Arjen:
>
> I am addressing you because you are our primary Windows platform expert, but I
> would be happy to hear from others here as well (including Alaric) with some
> knowledge of that platform.
>
> What would be your advice concerning replacing our use of the WIN32 and
> __WIN32__ macros in our source code?
>
> Basically, Alaric (see his bug report below) has found a platform where the _WIN32
> macro is #defined but not WIN32, and the stackoverflow discussion he referenced
> appears to say the two macros ordinarily have the same meaning but the
> underscored one is a bit safer to use because there is a convention it should not be
> changed by anyone other than the compiler vendor.
>
> Note, however, that Alaric's bug report does not cover the entire problem in our
> code because we also make use of the __WIN32__ macro.
> Another stackoverflow discussion concerning that macro referenced
> <https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/
> 2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
> >.
>
> My conclusion from reading the "Windows, Cygwin (non-POSIX), and MinGW"
> section of that article is the safest course for supporting all Windows compilers is
> for us to replace all use of the WIN32 and __WIN32__ macros in our C and C++
> code with use of the _WIN32 macro instead.  Do you agree?
>
> If so, I would be willing to take responsibility for the actual code change since Linux
> has excellent facilities (find and
> sed) for automatic mass-editing of code.
>
> 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
> __________________________
>
> ---------- Forwarded message ----------
> Date: Mon, 09 Oct 2017 15:52:10 +0000
> From: Alaric Senat <ala...@us...>
> Reply-To: Ticket 189 <18...@bu...>
> To: Ticket 189 <18...@bu...>
> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
>
>
>
>
> ---
>
> ** [bugs:#189] Using WIN32 Macro instead of _WIN32**
>
> **Status:** open
> **Group:**
> **Created:** Mon Oct 09, 2017 03:52 PM UTC by Alaric Senat **Last Updated:**
> Mon Oct 09, 2017 03:52 PM UTC
> **Owner:** nobody
>
>
> Hello,
>
> This ticket is just about a little detail and its not exactly a bug.
> Me and my team are cross-compiling for windows, and we noticed that you are
> often using the WIN32 macro in your source files to check the current compilator
> platform.
> We needed to switch these macros to \_WIN32 because in our case, we are
> compiling with the *-std=c++14* flag and is disable WIN32 cause it's not in the
> standard.
> To my mind, It would be a bit safer if those WIN32 were switched to \_WIN32 in a
> further version of PlPlot!
>
> Here is a nice topic on that point :
> https://stackoverflow.com/questions/662084/whats-the-difference-between-the-
> win32-and-win32-defines-in-c/662543#662543
>
> Regards,
> Alaric Senat
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in
> <https://sourceforge.net/p/plplot/bugs/189/>
>
>
>
> To unsubscribe from further messages, please visit
> <https://sourceforge.net/auth/subscriptions/>

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.