plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Excellent, thanks Alan
On Sun, 23 Sep 2018 at 01:25, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
> > Hi Laurent
> >
> > I have implemented your first solution. If you could let me know that
> > things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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] Cannot compile plplot using VS 2017

[Alan W. I. <Ala...@gm...>]

On 2018-09-22 23:16+0100 Phil Rosenberg wrote:

> Hi Laurent
>
> I have implemented your first solution. If you could let me know that
> things now work for you that would be great.

Hi Phil:

Although your question was addressed to Laurent, it should interest
you to know your fix causes no issues for Linux (i.e., building the
test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
or run-time issues).

Alan
__________________________
Alan W. Irwin

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 now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

Hi Ole:

I have just now updated PLplot (commit d2d9461a3) to allow our build
system to use local builds of Lua in a consistent fashion, and using
that capability I have proved the Debian Lua-5.3.3 issue is in
upstream 5.3.3 which is fixed in upstream 5.3.5 (see the latest
discussion at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for more
details).

Furthermore, if you look at <https://tracker.debian.org/pkg/lua5.3>
the official maintainer has been inactive for the last three years so
others have been occasionally contributing with the last such activity
a year ago.  Therefore, would you be willing to do a NMU of lua-5.3.5
to allow the upstream fix for the lua issue I have been discussing to
propagate to Debian?  Such propagation should simplify your life
as the Debian maintainer for PLplot as well as being a big help
to each Debian user who is encountering this severe issue with Lua-5.3.3.

Alan
__________________________
Alan W. Irwin

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] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Hi Laurent

I have implemented your first solution. If you could let me know that
things now work for you that would be great.

Thanks

Phil
On Sat, 22 Sep 2018 at 11:44, Laurent Berger
<lau...@un...> wrote:
>
> I tried  2 solutions :
>
> FIRST solution
>
> don't change wxwidgets_dev.cpp
>
> and change include order in wxwidgets.h #include <wx/wx.h> after
> <memory> and before  // plplot headers
>
> then  $ git diff is
> diff --git a/drivers/wxwidgets.h b/drivers/wxwidgets.h
> index 884292d07..0818f357c 100644
> --- a/drivers/wxwidgets.h
> +++ b/drivers/wxwidgets.h
> @@ -22,13 +22,14 @@
>
>   #include <vector>
>   #include <memory>
> +#include <wx/wx.h>
>
>   // plplot headers
>   #include "plplotP.h"
>   #include "wxwidgets_comms.h"
>
>   // some special wxWidgets headers
> -#include <wx/wx.h>
> +//#include <wx/wx.h>
>   #include <wx/spinctrl.h>
>   #include <wx/dcgraph.h>
>
> SECOND solution
>
> add #include <wx/wx.h> in wxwidgets_dev.cpp at line 41
>
> then $git diff is
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 6351c6893..07089d83a 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -38,7 +38,7 @@
>   #else
>   #include <fstream>
>   #endif
> -
> +#include <wx/wx.h>
>   // PLplot headers
>   #include "plDevs.h"
>   #include "wxwidgets.h" // includes wx/wx.h
>
>
>
> Le 22/09/2018 à 12:26, Phil Rosenberg a écrit :
> > Hi Laurent
> >
> > Okay, well if your solution works, the I think we should add it in.
> >
> > Could I please ask for you to check what the minimum list of headers
> > to be included needs to be? Would just adding wx/wx.h be sufficient or
> > do all those headers need to be added?
> >
> > Phil
> >
> > Phil
> > On Sat, 22 Sep 2018 at 10:24, Laurent Berger
> > <lau...@un...> wrote:
> >> Hi Phil, Alan,
> >>
> >> I check everything this morning (local time) and I have got same errors.
> >>
> >> I attached my cmakecache for plplot and cmakecache for wxwidgets
> >>
> >> git diff
> >>
> >> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
> >> $ git diff
> >> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> >> index 6351c6893..27b20750e 100644
> >> --- a/drivers/wxwidgets_dev.cpp
> >> +++ b/drivers/wxwidgets_dev.cpp
> >> @@ -38,7 +38,15 @@
> >>    #else
> >>    #include <fstream>
> >>    #endif
> >> +#include <wx/wx.h>
> >> +#include <wx/wfstream.h>
> >> +#include <wx/except.h>
> >>
> >> +#include "plDevs.h"
> >> +
> >> +// plplot headers
> >> +#include "plplotP.h"
> >> +#include "drivers.h"
> >>    // PLplot headers
> >>    #include "plDevs.h"
> >>    #include "wxwidgets.h" // includes wx/wx.h
> >>
> >>
> >>
> >>
> >> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> >>> Hi Laurent
> >>> What a strange set of compilation errors. They are all from windows
> >>> sockets headers, rather than from wxWidgets.
> >>>
> >>> Here is my guess at what is happening - but I have not been able to
> >>> reproduce the error (I am using VS 2015 still).
> >>>
> >>> In the code before your edits following the #includes through, it
> >>> turns out we include <windows.h> into wxwidgets_dev.cpp before any
> >>> wxWidgets headers. This is done via "wxwidgets.h", then
> >>> "wxwidgets_comms.h". The winsock related functions probably get pulled
> >>> in via windows.h. I have a feeling that one of the wx headers is then
> >>> pulling in alternate definitions of those winsock functions, but I'm
> >>> not sure from where.
> >>>
> >>> By shuffling the headers round as you have, you include <wx/wx.h>
> >>> before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
> >>> <windows.h> itself. then our include windows.h should get ignored.
> >>>
> >>> I can't think how exectly it might work, but I bet there is some weird
> >>> inconsistency between how <windows.h> is pulled in by us, vs how it is
> >>> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> >>> or extern "C".
> >>>
> >>> Anyway I might guess that moving the headers around is simply masking
> >>> some other problem. Can I check that you have built wxWidgets with the
> >>> same virsion of visual studio? And that it is also built as a static
> >>> lib? Just a hunch but maybe something to do with the wxwidgets library
> >>> configuration is causing the issue.
> >>>
> >>> Phil
> >>> On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
> >>>> On 2018-09-21 18:38+0200 Laurent Berger wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> >>>>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >>>>>
> >>>>> and delete cmakecache.txt and I I'm trying to build plplot in static
> >>>>>
> >>>>> BUILD_SHARED_LIBS:BOOL=OFF
> >>>>>
> >>>>> and ENABLE_DYNDRIVERS:BOOL=OFF
> >>>>>
> >>>>> and I have got 59 errors compiling wxwidgets_dev.cpp.
> >>>>>
> >>>>> In git repo I can find this file
> >>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >>>>>
> >>>>> I copy
> >>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> >>>>> and insert those lines here
> >>>>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >>>>>
> >>>>> I can compile and link plplot.
> >>>> Hi Laurent:
> >>>>
> >>>> Thanks for your test of my recent PLplot development activity.
> >>>>
> >>>> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> >>>> and caf4801dfe (current master tip), and your description of the
> >>>> required change appears to correspond to copying some wxwidgets includes from
> >>>> one part of the old commit (or alternatively the latest commit since
> >>>> those lines haven't changed) to just after
> >>>>
> >>>> #include "wxwidgets.h"
> >>>>
> >>>> As far as I can tell such a copy of includes should have zero effect
> >>>> so it appears either I misunderstood the change you described above or
> >>>> else the github repo for PLplot is not properly up to date with the
> >>>> definitive SourceForge repo.  So to remove this uncertainty please
> >>>> give us the results of
> >>>>
> >>>> git diff
> >>>>
> >>>> to describe the definitive version of the change to the master tip of
> >>>> PLplot that works for you (i.e., allows a static build of PLplot to
> >>>> compile and link for your VS2017 platform).
> >>>>
> >>>> By the way, a comprehensive test of PLplot has recently (one commit
> >>>> behind master tip) worked perfectly here on Linux (Debian Buster).
> >>>> Such comprehensive tests include not only building a static wxwidgets
> >>>> device but run-time testing it as well.  Also that last commit on the
> >>>> master branch is a minor one involving how to control the Lua version
> >>>> that is searched for and is therefore extremely unlikely to introduce
> >>>> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> >>>> so someone with access to recent Windows platforms will have to
> >>>> attempt that instead.
> >>>>
> >>>> Alan
> >>>> __________________________
> >>>> Alan W. Irwin
> >>>>
> >>>> 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 mailing list
> >>>> Plp...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

I tried  2 solutions :

FIRST solution

don't change wxwidgets_dev.cpp

and change include order in wxwidgets.h #include <wx/wx.h> after 
<memory> and before  // plplot headers

then  $ git diff is
diff --git a/drivers/wxwidgets.h b/drivers/wxwidgets.h
index 884292d07..0818f357c 100644
--- a/drivers/wxwidgets.h
+++ b/drivers/wxwidgets.h
@@ -22,13 +22,14 @@

  #include <vector>
  #include <memory>
+#include <wx/wx.h>

  // plplot headers
  #include "plplotP.h"
  #include "wxwidgets_comms.h"

  // some special wxWidgets headers
-#include <wx/wx.h>
+//#include <wx/wx.h>
  #include <wx/spinctrl.h>
  #include <wx/dcgraph.h>

SECOND solution

add #include <wx/wx.h> in wxwidgets_dev.cpp at line 41

then $git diff is
diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
index 6351c6893..07089d83a 100644
--- a/drivers/wxwidgets_dev.cpp
+++ b/drivers/wxwidgets_dev.cpp
@@ -38,7 +38,7 @@
  #else
  #include <fstream>
  #endif
-
+#include <wx/wx.h>
  // PLplot headers
  #include "plDevs.h"
  #include "wxwidgets.h" // includes wx/wx.h



Le 22/09/2018 à 12:26, Phil Rosenberg a écrit :
> Hi Laurent
>
> Okay, well if your solution works, the I think we should add it in.
>
> Could I please ask for you to check what the minimum list of headers
> to be included needs to be? Would just adding wx/wx.h be sufficient or
> do all those headers need to be added?
>
> Phil
>
> Phil
> On Sat, 22 Sep 2018 at 10:24, Laurent Berger
> <lau...@un...> wrote:
>> Hi Phil, Alan,
>>
>> I check everything this morning (local time) and I have got same errors.
>>
>> I attached my cmakecache for plplot and cmakecache for wxwidgets
>>
>> git diff
>>
>> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
>> $ git diff
>> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
>> index 6351c6893..27b20750e 100644
>> --- a/drivers/wxwidgets_dev.cpp
>> +++ b/drivers/wxwidgets_dev.cpp
>> @@ -38,7 +38,15 @@
>>    #else
>>    #include <fstream>
>>    #endif
>> +#include <wx/wx.h>
>> +#include <wx/wfstream.h>
>> +#include <wx/except.h>
>>
>> +#include "plDevs.h"
>> +
>> +// plplot headers
>> +#include "plplotP.h"
>> +#include "drivers.h"
>>    // PLplot headers
>>    #include "plDevs.h"
>>    #include "wxwidgets.h" // includes wx/wx.h
>>
>>
>>
>>
>> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
>>> Hi Laurent
>>> What a strange set of compilation errors. They are all from windows
>>> sockets headers, rather than from wxWidgets.
>>>
>>> Here is my guess at what is happening - but I have not been able to
>>> reproduce the error (I am using VS 2015 still).
>>>
>>> In the code before your edits following the #includes through, it
>>> turns out we include <windows.h> into wxwidgets_dev.cpp before any
>>> wxWidgets headers. This is done via "wxwidgets.h", then
>>> "wxwidgets_comms.h". The winsock related functions probably get pulled
>>> in via windows.h. I have a feeling that one of the wx headers is then
>>> pulling in alternate definitions of those winsock functions, but I'm
>>> not sure from where.
>>>
>>> By shuffling the headers round as you have, you include <wx/wx.h>
>>> before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
>>> <windows.h> itself. then our include windows.h should get ignored.
>>>
>>> I can't think how exectly it might work, but I bet there is some weird
>>> inconsistency between how <windows.h> is pulled in by us, vs how it is
>>> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
>>> or extern "C".
>>>
>>> Anyway I might guess that moving the headers around is simply masking
>>> some other problem. Can I check that you have built wxWidgets with the
>>> same virsion of visual studio? And that it is also built as a static
>>> lib? Just a hunch but maybe something to do with the wxwidgets library
>>> configuration is causing the issue.
>>>
>>> Phil
>>> On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
>>>> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
>>>>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
>>>>>
>>>>> and delete cmakecache.txt and I I'm trying to build plplot in static
>>>>>
>>>>> BUILD_SHARED_LIBS:BOOL=OFF
>>>>>
>>>>> and ENABLE_DYNDRIVERS:BOOL=OFF
>>>>>
>>>>> and I have got 59 errors compiling wxwidgets_dev.cpp.
>>>>>
>>>>> In git repo I can find this file
>>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
>>>>>
>>>>> I copy
>>>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
>>>>> and insert those lines here
>>>>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
>>>>>
>>>>> I can compile and link plplot.
>>>> Hi Laurent:
>>>>
>>>> Thanks for your test of my recent PLplot development activity.
>>>>
>>>> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
>>>> and caf4801dfe (current master tip), and your description of the
>>>> required change appears to correspond to copying some wxwidgets includes from
>>>> one part of the old commit (or alternatively the latest commit since
>>>> those lines haven't changed) to just after
>>>>
>>>> #include "wxwidgets.h"
>>>>
>>>> As far as I can tell such a copy of includes should have zero effect
>>>> so it appears either I misunderstood the change you described above or
>>>> else the github repo for PLplot is not properly up to date with the
>>>> definitive SourceForge repo.  So to remove this uncertainty please
>>>> give us the results of
>>>>
>>>> git diff
>>>>
>>>> to describe the definitive version of the change to the master tip of
>>>> PLplot that works for you (i.e., allows a static build of PLplot to
>>>> compile and link for your VS2017 platform).
>>>>
>>>> By the way, a comprehensive test of PLplot has recently (one commit
>>>> behind master tip) worked perfectly here on Linux (Debian Buster).
>>>> Such comprehensive tests include not only building a static wxwidgets
>>>> device but run-time testing it as well.  Also that last commit on the
>>>> master branch is a minor one involving how to control the Lua version
>>>> that is searched for and is therefore extremely unlikely to introduce
>>>> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
>>>> so someone with access to recent Windows platforms will have to
>>>> attempt that instead.
>>>>
>>>> Alan
>>>> __________________________
>>>> Alan W. Irwin
>>>>
>>>> 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 mailing list
>>>> Plp...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Hi Laurent

Okay, well if your solution works, the I think we should add it in.

Could I please ask for you to check what the minimum list of headers
to be included needs to be? Would just adding wx/wx.h be sufficient or
do all those headers need to be added?

Phil

Phil
On Sat, 22 Sep 2018 at 10:24, Laurent Berger
<lau...@un...> wrote:
>
> Hi Phil, Alan,
>
> I check everything this morning (local time) and I have got same errors.
>
> I attached my cmakecache for plplot and cmakecache for wxwidgets
>
> git diff
>
> Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
> $ git diff
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 6351c6893..27b20750e 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -38,7 +38,15 @@
>   #else
>   #include <fstream>
>   #endif
> +#include <wx/wx.h>
> +#include <wx/wfstream.h>
> +#include <wx/except.h>
>
> +#include "plDevs.h"
> +
> +// plplot headers
> +#include "plplotP.h"
> +#include "drivers.h"
>   // PLplot headers
>   #include "plDevs.h"
>   #include "wxwidgets.h" // includes wx/wx.h
>
>
>
>
> Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> > Hi Laurent
> > What a strange set of compilation errors. They are all from windows
> > sockets headers, rather than from wxWidgets.
> >
> > Here is my guess at what is happening - but I have not been able to
> > reproduce the error (I am using VS 2015 still).
> >
> > In the code before your edits following the #includes through, it
> > turns out we include <windows.h> into wxwidgets_dev.cpp before any
> > wxWidgets headers. This is done via "wxwidgets.h", then
> > "wxwidgets_comms.h". The winsock related functions probably get pulled
> > in via windows.h. I have a feeling that one of the wx headers is then
> > pulling in alternate definitions of those winsock functions, but I'm
> > not sure from where.
> >
> > By shuffling the headers round as you have, you include <wx/wx.h>
> > before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
> > <windows.h> itself. then our include windows.h should get ignored.
> >
> > I can't think how exectly it might work, but I bet there is some weird
> > inconsistency between how <windows.h> is pulled in by us, vs how it is
> > pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> > or extern "C".
> >
> > Anyway I might guess that moving the headers around is simply masking
> > some other problem. Can I check that you have built wxWidgets with the
> > same virsion of visual studio? And that it is also built as a static
> > lib? Just a hunch but maybe something to do with the wxwidgets library
> > configuration is causing the issue.
> >
> > Phil
> > On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
> >> On 2018-09-21 18:38+0200 Laurent Berger wrote:
> >>
> >>> Hi,
> >>>
> >>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> >>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >>>
> >>> and delete cmakecache.txt and I I'm trying to build plplot in static
> >>>
> >>> BUILD_SHARED_LIBS:BOOL=OFF
> >>>
> >>> and ENABLE_DYNDRIVERS:BOOL=OFF
> >>>
> >>> and I have got 59 errors compiling wxwidgets_dev.cpp.
> >>>
> >>> In git repo I can find this file
> >>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >>>
> >>> I copy
> >>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> >>> and insert those lines here
> >>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >>>
> >>> I can compile and link plplot.
> >> Hi Laurent:
> >>
> >> Thanks for your test of my recent PLplot development activity.
> >>
> >> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> >> and caf4801dfe (current master tip), and your description of the
> >> required change appears to correspond to copying some wxwidgets includes from
> >> one part of the old commit (or alternatively the latest commit since
> >> those lines haven't changed) to just after
> >>
> >> #include "wxwidgets.h"
> >>
> >> As far as I can tell such a copy of includes should have zero effect
> >> so it appears either I misunderstood the change you described above or
> >> else the github repo for PLplot is not properly up to date with the
> >> definitive SourceForge repo.  So to remove this uncertainty please
> >> give us the results of
> >>
> >> git diff
> >>
> >> to describe the definitive version of the change to the master tip of
> >> PLplot that works for you (i.e., allows a static build of PLplot to
> >> compile and link for your VS2017 platform).
> >>
> >> By the way, a comprehensive test of PLplot has recently (one commit
> >> behind master tip) worked perfectly here on Linux (Debian Buster).
> >> Such comprehensive tests include not only building a static wxwidgets
> >> device but run-time testing it as well.  Also that last commit on the
> >> master branch is a minor one involving how to control the Lua version
> >> that is searched for and is therefore extremely unlikely to introduce
> >> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> >> so someone with access to recent Windows platforms will have to
> >> attempt that instead.
> >>
> >> Alan
> >> __________________________
> >> Alan W. Irwin
> >>
> >> 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 mailing list
> >> Plp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

Hi Phil, Alan,

I check everything this morning (local time) and I have got same errors.

I attached my cmakecache for plplot and cmakecache for wxwidgets

git diff

Laurent@PC-Laurent-Vision MINGW64 /g/lib/plplot (master)
$ git diff
diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
index 6351c6893..27b20750e 100644
--- a/drivers/wxwidgets_dev.cpp
+++ b/drivers/wxwidgets_dev.cpp
@@ -38,7 +38,15 @@
  #else
  #include <fstream>
  #endif
+#include <wx/wx.h>
+#include <wx/wfstream.h>
+#include <wx/except.h>

+#include "plDevs.h"
+
+// plplot headers
+#include "plplotP.h"
+#include "drivers.h"
  // PLplot headers
  #include "plDevs.h"
  #include "wxwidgets.h" // includes wx/wx.h




Le 22/09/2018 à 01:37, Phil Rosenberg a écrit :
> Hi Laurent
> What a strange set of compilation errors. They are all from windows
> sockets headers, rather than from wxWidgets.
>
> Here is my guess at what is happening - but I have not been able to
> reproduce the error (I am using VS 2015 still).
>
> In the code before your edits following the #includes through, it
> turns out we include <windows.h> into wxwidgets_dev.cpp before any
> wxWidgets headers. This is done via "wxwidgets.h", then
> "wxwidgets_comms.h". The winsock related functions probably get pulled
> in via windows.h. I have a feeling that one of the wx headers is then
> pulling in alternate definitions of those winsock functions, but I'm
> not sure from where.
>
> By shuffling the headers round as you have, you include <wx/wx.h>
> before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
> <windows.h> itself. then our include windows.h should get ignored.
>
> I can't think how exectly it might work, but I bet there is some weird
> inconsistency between how <windows.h> is pulled in by us, vs how it is
> pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
> or extern "C".
>
> Anyway I might guess that moving the headers around is simply masking
> some other problem. Can I check that you have built wxWidgets with the
> same virsion of visual studio? And that it is also built as a static
> lib? Just a hunch but maybe something to do with the wxwidgets library
> configuration is causing the issue.
>
> Phil
> On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
>> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>>
>>> Hi,
>>>
>>> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
>>> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
>>>
>>> and delete cmakecache.txt and I I'm trying to build plplot in static
>>>
>>> BUILD_SHARED_LIBS:BOOL=OFF
>>>
>>> and ENABLE_DYNDRIVERS:BOOL=OFF
>>>
>>> and I have got 59 errors compiling wxwidgets_dev.cpp.
>>>
>>> In git repo I can find this file
>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
>>>
>>> I copy
>>> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
>>> and insert those lines here
>>> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
>>>
>>> I can compile and link plplot.
>> Hi Laurent:
>>
>> Thanks for your test of my recent PLplot development activity.
>>
>> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
>> and caf4801dfe (current master tip), and your description of the
>> required change appears to correspond to copying some wxwidgets includes from
>> one part of the old commit (or alternatively the latest commit since
>> those lines haven't changed) to just after
>>
>> #include "wxwidgets.h"
>>
>> As far as I can tell such a copy of includes should have zero effect
>> so it appears either I misunderstood the change you described above or
>> else the github repo for PLplot is not properly up to date with the
>> definitive SourceForge repo.  So to remove this uncertainty please
>> give us the results of
>>
>> git diff
>>
>> to describe the definitive version of the change to the master tip of
>> PLplot that works for you (i.e., allows a static build of PLplot to
>> compile and link for your VS2017 platform).
>>
>> By the way, a comprehensive test of PLplot has recently (one commit
>> behind master tip) worked perfectly here on Linux (Debian Buster).
>> Such comprehensive tests include not only building a static wxwidgets
>> device but run-time testing it as well.  Also that last commit on the
>> master branch is a minor one involving how to control the Lua version
>> that is searched for and is therefore extremely unlikely to introduce
>> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
>> so someone with access to recent Windows platforms will have to
>> attempt that instead.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> 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 mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Phil R. <p.d...@gm...>]

Hi Laurent
What a strange set of compilation errors. They are all from windows
sockets headers, rather than from wxWidgets.

Here is my guess at what is happening - but I have not been able to
reproduce the error (I am using VS 2015 still).

In the code before your edits following the #includes through, it
turns out we include <windows.h> into wxwidgets_dev.cpp before any
wxWidgets headers. This is done via "wxwidgets.h", then
"wxwidgets_comms.h". The winsock related functions probably get pulled
in via windows.h. I have a feeling that one of the wx headers is then
pulling in alternate definitions of those winsock functions, but I'm
not sure from where.

By shuffling the headers round as you have, you include <wx/wx.h>
before we pull in <windows.h>. The <wx/wx.h> file will in turn pull in
<windows.h> itself. then our include windows.h should get ignored.

I can't think how exectly it might work, but I bet there is some weird
inconsistency between how <windows.h> is pulled in by us, vs how it is
pulled in by wxWidgets - maybe related to some #defines like DLLEXPORT
or extern "C".

Anyway I might guess that moving the headers around is simply masking
some other problem. Can I check that you have built wxWidgets with the
same virsion of visual studio? And that it is also built as a static
lib? Just a hunch but maybe something to do with the wxwidgets library
configuration is causing the issue.

Phil
On Fri, 21 Sep 2018 at 23:08, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-21 18:38+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> > ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
> >
> > and delete cmakecache.txt and I I'm trying to build plplot in static
> >
> > BUILD_SHARED_LIBS:BOOL=OFF
> >
> > and ENABLE_DYNDRIVERS:BOOL=OFF
> >
> > and I have got 59 errors compiling wxwidgets_dev.cpp.
> >
> > In git repo I can find this file
> > https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
> >
> > I copy
> > https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36
> > and insert those lines here
> > https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
> >
> > I can compile and link plplot.
>
> Hi Laurent:
>
> Thanks for your test of my recent PLplot development activity.
>
> I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
> and caf4801dfe (current master tip), and your description of the
> required change appears to correspond to copying some wxwidgets includes from
> one part of the old commit (or alternatively the latest commit since
> those lines haven't changed) to just after
>
> #include "wxwidgets.h"
>
> As far as I can tell such a copy of includes should have zero effect
> so it appears either I misunderstood the change you described above or
> else the github repo for PLplot is not properly up to date with the
> definitive SourceForge repo.  So to remove this uncertainty please
> give us the results of
>
> git diff
>
> to describe the definitive version of the change to the master tip of
> PLplot that works for you (i.e., allows a static build of PLplot to
> compile and link for your VS2017 platform).
>
> By the way, a comprehensive test of PLplot has recently (one commit
> behind master tip) worked perfectly here on Linux (Debian Buster).
> Such comprehensive tests include not only building a static wxwidgets
> device but run-time testing it as well.  Also that last commit on the
> master branch is a minor one involving how to control the Lua version
> that is searched for and is therefore extremely unlikely to introduce
> wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
> so someone with access to recent Windows platforms will have to
> attempt that instead.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cannot compile plplot using VS 2017

[Alan W. I. <Ala...@gm...>]

On 2018-09-21 18:38+0200 Laurent Berger wrote:

> Hi,
>
> I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
> ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
>
> and delete cmakecache.txt and I I'm trying to build plplot in static
>
> BUILD_SHARED_LIBS:BOOL=OFF
>
> and ENABLE_DYNDRIVERS:BOOL=OFF
>
> and I have got 59 errors compiling wxwidgets_dev.cpp.
>
> In git repo I can find this file 
> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp
>
> I copy 
> https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36 
> and insert those lines here 
> https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41
>
> I can compile and link plplot.

Hi Laurent:

Thanks for your test of my recent PLplot development activity.

I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9)
and caf4801dfe (current master tip), and your description of the
required change appears to correspond to copying some wxwidgets includes from
one part of the old commit (or alternatively the latest commit since
those lines haven't changed) to just after

#include "wxwidgets.h"

As far as I can tell such a copy of includes should have zero effect
so it appears either I misunderstood the change you described above or
else the github repo for PLplot is not properly up to date with the
definitive SourceForge repo.  So to remove this uncertainty please
give us the results of

git diff

to describe the definitive version of the change to the master tip of
PLplot that works for you (i.e., allows a static build of PLplot to
compile and link for your VS2017 platform).

By the way, a comprehensive test of PLplot has recently (one commit
behind master tip) worked perfectly here on Linux (Debian Buster).
Such comprehensive tests include not only building a static wxwidgets
device but run-time testing it as well.  Also that last commit on the
master branch is a minor one involving how to control the Lua version
that is searched for and is therefore extremely unlikely to introduce
wxwidgets issues.  Therefore, I cannot replicate your issue on Linux
so someone with access to recent Windows platforms will have to
attempt that instead.

Alan
__________________________
Alan W. Irwin

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] Cannot compile plplot using VS 2017

[Laurent B. <lau...@un...>]

Hi,

I have just done a git clone : (Date:   Thu Sep 20 22:36:48 2018 -0700
) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d

and delete cmakecache.txt and I I'm trying to build plplot in static

BUILD_SHARED_LIBS:BOOL=OFF

and ENABLE_DYNDRIVERS:BOOL=OFF

and I have got 59 errors compiling wxwidgets_dev.cpp.

In git repo I can find this file 
https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp

I copy 
https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36 
and insert those lines here 
https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41

I can compile and link plplot.




Errors list compiling wxwidgets_dev.cpp:

1>wxwidgets_dev.cpp
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(103): warning C4005: 
'AF_IPX': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(457): note: see previous 
definition of 'AF_IPX'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(147): warning C4005: 
'AF_MAX': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(476): note: see previous 
definition of 'AF_MAX'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(185): warning C4005: 
'SO_DONTLINGER': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(399): note: see previous 
definition of 'SO_DONTLINGER'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011: 
'sockaddr': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1007): note: see declaration 
of 'sockaddr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C2059: syntax 
error: 'constant'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C3805: 
'constant': unexpected token, expected either '}' or a ','
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(572): warning C4005: 
'IN_CLASSA': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(284): note: see previous 
definition of 'IN_CLASSA'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(578): warning C4005: 
'IN_CLASSB': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(290): note: see previous 
definition of 'IN_CLASSB'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(584): warning C4005: 
'IN_CLASSC': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(296): note: see previous 
definition of 'IN_CLASSC'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(595): warning C4005: 
'INADDR_ANY': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(301): note: see previous 
definition of 'INADDR_ANY'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(597): warning C4005: 
'INADDR_BROADCAST': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(303): note: see previous 
definition of 'INADDR_BROADCAST'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(633): error C2011: 
'sockaddr_in': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1011): note: see declaration 
of 'sockaddr_in'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(136): error C2011: 'fd_set': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1019): note: see declaration 
of 'fd_set'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(156): warning C4005: 
'FD_CLR': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(94): note: see previous 
definition of 'FD_CLR'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(171): warning C4005: 
'FD_SET': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(99): note: see previous 
definition of 'FD_SET'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(180): error C2011: 'timeval': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1035): note: see declaration 
of 'timeval'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(236): error C2011: 'hostent': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1023): note: see declaration 
of 'hostent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(249): error C2011: 'netent': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(177): note: see declaration of 
'netent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(256): error C2011: 'servent': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1027): note: see declaration 
of 'servent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(268): error C2011: 
'protoent': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1031): note: see declaration 
of 'protoent'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(364): error C2011: 'WSAData': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(319): note: see declaration of 
'WSAData'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(462): error C2011: 
'sockproto': 'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(491): note: see declaration of 
'sockproto'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(504): error C2011: 'linger': 
'struct' type redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(1015): note: see declaration 
of 'linger'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(517): warning C4005: 
'SOMAXCONN': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(541): note: see previous 
definition of 'SOMAXCONN'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(551): warning C4005: 
'FD_READ': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(559): note: see previous 
definition of 'FD_READ'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(554): warning C4005: 
'FD_WRITE': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(560): note: see previous 
definition of 'FD_WRITE'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(557): warning C4005: 
'FD_OOB': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(561): note: see previous 
definition of 'FD_OOB'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(560): warning C4005: 
'FD_ACCEPT': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(562): note: see previous 
definition of 'FD_ACCEPT'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(563): warning C4005: 
'FD_CONNECT': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(563): note: see previous 
definition of 'FD_CONNECT'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(566): warning C4005: 
'FD_CLOSE': macro redefinition
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(564): note: see previous 
definition of 'FD_CLOSE'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1624): error C2375: 'accept': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(739): note: see declaration of 
'accept'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1646): error C2375: 'bind': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(744): note: see declaration of 
'bind'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1667): error C2375: 
'closesocket': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(749): note: see declaration of 
'closesocket'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1684): error C2375: 
'connect': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(751): note: see declaration of 
'connect'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1705): error C2375: 
'ioctlsocket': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(756): note: see declaration of 
'ioctlsocket'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1728): error C2375: 
'getpeername': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(761): note: see declaration of 
'getpeername'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1749): error C2375: 
'getsockname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(766): note: see declaration of 
'getsockname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1770): error C2375: 
'getsockopt': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(771): note: see declaration of 
'getsockopt'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1795): error C2375: 'htonl': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(778): note: see declaration of 
'htonl'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1812): error C2375: 'htons': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(780): note: see declaration of 
'htons'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1830): error C2375: 
'inet_addr': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(782): note: see declaration of 
'inet_addr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1848): error C2375: 
'inet_ntoa': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(784): note: see declaration of 
'inet_ntoa'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1948): error C2375: 'listen': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(786): note: see declaration of 
'listen'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1967): error C2375: 'ntohl': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(790): note: see declaration of 
'ntohl'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(1984): error C2375: 'ntohs': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(792): note: see declaration of 
'ntohs'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2001): error C2375: 'recv': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(794): note: see declaration of 
'recv'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2024): error C2375: 
'recvfrom': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(800): note: see declaration of 
'recvfrom'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2051): error C2375: 'select': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(808): note: see declaration of 
'select'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2076): error C2375: 'send': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(815): note: see declaration of 
'send'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2099): error C2375: 'sendto': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(821): note: see declaration of 
'sendto'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2126): error C2375: 
'setsockopt': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(829): note: see declaration of 
'setsockopt'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2151): error C2375: 
'shutdown': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(836): note: see declaration of 
'shutdown'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2171): error C2375: 'socket': 
redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(840): note: see declaration of 
'socket'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2196): error C2375: 
'gethostbyaddr': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(847): note: see declaration of 
'gethostbyaddr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2218): error C2375: 
'gethostbyname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(852): note: see declaration of 
'gethostbyname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2235): error C2375: 
'gethostname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(854): note: see declaration of 
'gethostname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2275): error C2375: 
'getservbyport': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(858): note: see declaration of 
'getservbyport'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2294): error C2375: 
'getservbyname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(862): note: see declaration of 
'getservbyname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2313): error C2375: 
'getprotobynumber': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(866): note: see declaration of 
'getprotobynumber'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2330): error C2375: 
'getprotobyname': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(868): note: see declaration of 
'getprotobyname'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2350): error C2375: 
'WSAStartup': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(872): note: see declaration of 
'WSAStartup'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2370): error C2375: 
'WSACleanup': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(876): note: see declaration of 
'WSACleanup'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2387): error C2375: 
'WSASetLastError': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(878): note: see declaration of 
'WSASetLastError'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2404): error C2375: 
'WSAGetLastError': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(880): note: see declaration of 
'WSAGetLastError'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2425): error C2375: 
'WSAIsBlocking': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(882): note: see declaration of 
'WSAIsBlocking'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2443): error C2375: 
'WSAUnhookBlockingHook': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(884): note: see declaration of 
'WSAUnhookBlockingHook'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2461): error C2375: 
'WSASetBlockingHook': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(886): note: see declaration of 
'WSASetBlockingHook'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2479): error C2375: 
'WSACancelBlockingCall': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(888): note: see declaration of 
'WSACancelBlockingCall'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2497): error C2375: 
'WSAAsyncGetServByName': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(890): note: see declaration of 
'WSAAsyncGetServByName'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2525): error C2375: 
'WSAAsyncGetServByPort': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(898): note: see declaration of 
'WSAAsyncGetServByPort'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2553): error C2375: 
'WSAAsyncGetProtoByName': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(906): note: see declaration of 
'WSAAsyncGetProtoByName'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2579): error C2375: 
'WSAAsyncGetProtoByNumber': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(913): note: see declaration of 
'WSAAsyncGetProtoByNumber'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2605): error C2375: 
'WSAAsyncGetHostByName': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(920): note: see declaration of 
'WSAAsyncGetHostByName'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2631): error C2375: 
'WSAAsyncGetHostByAddr': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(927): note: see declaration of 
'WSAAsyncGetHostByAddr'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2661): error C2375: 
'WSACancelAsyncRequest': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(936): note: see declaration of 
'WSACancelAsyncRequest'
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock2.h(2679): error C2375: 
'WSAAsyncSelect': redefinition; different linkage
1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\um\winsock.h(938): note: see declaration of 
'WSAAsyncSelect'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(736): warning C4996: 
'wxFont::wxFont': deprecated: use wxFONT{FAMILY,STYLE,WEIGHT}_XXX 
constants ie: wxFONTFAMILY_SWISS, wxFONTSTYLE_NORMAL, wxFONTWEIGHT_BOLD
1>g:\lib\install\wxwidgets\include\wx\msw\font.h(115): note: see 
declaration of 'wxFont::wxFont'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(1010): warning C4996: 
'wxPen::wxPen': deprecated: use wxPENSTYLE_XXX constants
1>g:\lib\install\wxwidgets\include\wx\msw\pen.h(58): note: see 
declaration of 'wxPen::wxPen'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(1045): warning C4996: 
'wxPen::wxPen': deprecated: use wxPENSTYLE_XXX constants
1>g:\lib\install\wxwidgets\include\wx\msw\pen.h(58): note: see 
declaration of 'wxPen::wxPen'
1>g:\lib\plplot\drivers\wxwidgets_dev.cpp(1058): warning C4996: 
'wxPen::wxPen': deprecated: use wxPENSTYLE_XXX constants
1>g:\lib\install\wxwidgets\include\wx\msw\pen.h(58): note: see 
declaration of 'wxPen::wxPen'
1>Done building project "plplot.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

1>c:\program files (x86)\windows 
kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011: 
'sockaddr': 'struct' type redefinition





Configuration

Cmake 3.11.0

VS 2017 win 64 Version 15.6.3

wxwidgets 3.1.2


Le 21/09/2018 à 05:09, Orion Poplawski a écrit :
> On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
>> On 2018-09-19 22:06-0600 Orion Poplawski wrote:
>>
>>> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>>>> To Orion and Ole:
>>>>
>>>> Commit a730ebe34 has removed the last of the "new software" issues I
>>>> have identified with Debian Testing = Buster.
>>>>
>>>> @Orion: I encourage you to try that commit on Fedora to see if you get
>>>> similarly good results for all Linux-available components of
>>>> PLplot for that other cutting-edge Linux platform.
>>>>
>>>> @Both: You both also might want to experiment with this commit as the
>>>> basis for much-improved PLplot packages for Fedora and Debian.
>>>> However such packages can only be considered preliminary until PLplot
>>>> makes an official release.  What I can say on that topic is commit
>>>> a730ebe34 is an important milestone on the trail to the next release,
>>>> but we are not there yet.
>>>>
>>>> For example, the CMake test that is automatically produced every night
>>>> by my computer for the CMake developers builds and tests the latest
>>>> CMake.  One of those tests is the PLplot contract test which tests
>>>> whether a build (but not test) of PLplot is successful. That test is
>>>> formally succeeding, but those PLplot builds are incomplete (with the
>>>> cairo device driver dropped) because of incompatibilities with the way
>>>> we configure our cairo device driver using internal details of the
>>>> CMake pkg-config capability.  Although the use of such internal
>>>> details has worked well over many years with few adjustments needed
>>>> for changes to those internal details with CMake version, it is again
>>>> no longer working with the very latest CMake.  This reflects the
>>>> fundamental fragility of any method that uses internal details.
>>>> Therefore, to deal with this issue my plan is to completely rewrite
>>>> our support for the cairo device using the official CMake pkg-config
>>>> support rather than internal details of that support.  And there are
>>>> also a few other topics I would like to squeeze into the next release.
>>>> So this makes the ETA of our next PLplot release still somewhat
>>>> uncertain, but I am still hoping to get it done this year (before
>>>> Christmas season) rather than early next year.
>>>
>>> Latest git (a9d9500c) built on Fedora Rawhide:
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>>>
>>> Despite the overall failure to build, looks mostly okay, but it 
>>> appears that you don't support lua 5.3:
>>>
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.2")
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.1")
>>> -- LUA_INCLUDE_DIR =
>>> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
>>> -- WARNING: Lua header and/or library not found. Disabling Lua binding
>>
>> Hi Orion:
>>
>> Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
>> for all but one example, but that one example exposed a Lua-5.3 bug
>> (at least for the Debian version of Lua5.3) that was severe
>> (arithmetic quit working if more than 8 (!) arrays were initialized).
>> See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
>> simple Lua script that triggers this Lua-5.3 bug and other details
>> about this bug.  I temporarily worked around the problem by using our
>> build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
>> in the absence of Lua5.1 or 5.2 our build system should just
>> cleanly drop the Lua PLplot component and continue).
>>
>> Please try that simple Lua script to see whether the Fedora version of
>> Lua-5.3 also has this severe bug.  If you do confirm, then that is
>> pretty good evidence it is a general Lua-5.3 bug (rather than just
>> Debian related), and in this case I would be willing to take this
>> issue to the Lua developers rather than waiting for some response to
>> my bug report from the Debian packagers.
>>
>> It appears from
>> <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
>> the blacklisting worked without actual build issues (as expected), but
>> the actual error you get is because your rpm logic is expecting Lua
>> files from PLplot that are not there because of the blacklisting.  So
>> your response to this issue likely depends on whether you can get the
>> above simple test script to work for Fedora's version of Lua5.3.  If
>> that test actually works for Fedora, then it appears the Lua5.3 issue
>> is simply a Debian packaging issue that has nothing to do with Fedora,
>> and you should edit cmake/modules/lua.cmake to make the slight change
>> to look first for 5.3, then 5.2, then 5.1.  However, if that test also
>> fails for you, and you think the upstream Lua5.3 fix is going to take
>> a while to get fixed, then you should change your rpm logic to drop
>> all the expected Lua results.
>>
>> Alan
>
> I replied to the debian bug.  It appears that lua 5.3.5 on Fedora 
> rawhide is fine.
>
>

Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

On 2018-09-20 21:09-0600 Orion Poplawski wrote:

> On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
>> On 2018-09-19 22:06-0600 Orion Poplawski wrote:
>> 
>>> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>>>> To Orion and Ole:
>>>> 
>>>> Commit a730ebe34 has removed the last of the "new software" issues I
>>>> have identified with Debian Testing = Buster.
>>>> 
>>>> @Orion: I encourage you to try that commit on Fedora to see if you get
>>>> similarly good results for all Linux-available components of
>>>> PLplot for that other cutting-edge Linux platform.
>>>> 
>>>> @Both: You both also might want to experiment with this commit as the
>>>> basis for much-improved PLplot packages for Fedora and Debian.
>>>> However such packages can only be considered preliminary until PLplot
>>>> makes an official release.  What I can say on that topic is commit
>>>> a730ebe34 is an important milestone on the trail to the next release,
>>>> but we are not there yet.
>>>> 
>>>> For example, the CMake test that is automatically produced every night
>>>> by my computer for the CMake developers builds and tests the latest
>>>> CMake.  One of those tests is the PLplot contract test which tests
>>>> whether a build (but not test) of PLplot is successful.  That test is
>>>> formally succeeding, but those PLplot builds are incomplete (with the
>>>> cairo device driver dropped) because of incompatibilities with the way
>>>> we configure our cairo device driver using internal details of the
>>>> CMake pkg-config capability.  Although the use of such internal
>>>> details has worked well over many years with few adjustments needed
>>>> for changes to those internal details with CMake version, it is again
>>>> no longer working with the very latest CMake.  This reflects the
>>>> fundamental fragility of any method that uses internal details.
>>>> Therefore, to deal with this issue my plan is to completely rewrite
>>>> our support for the cairo device using the official CMake pkg-config
>>>> support rather than internal details of that support.  And there are
>>>> also a few other topics I would like to squeeze into the next release.
>>>> So this makes the ETA of our next PLplot release still somewhat
>>>> uncertain, but I am still hoping to get it done this year (before
>>>> Christmas season) rather than early next year.
>>> 
>>> Latest git (a9d9500c) built on Fedora Rawhide:
>>> 
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>>> 
>>> Despite the overall failure to build, looks mostly okay, but it appears 
>>> that you don't support lua 5.3:
>>> 
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.2")
>>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>>> version "5.1")
>>> -- LUA_INCLUDE_DIR =
>>> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
>>> -- WARNING: Lua header and/or library not found. Disabling Lua binding
>> 
>> Hi Orion:
>> 
>> Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
>> for all but one example, but that one example exposed a Lua-5.3 bug
>> (at least for the Debian version of Lua5.3) that was severe
>> (arithmetic quit working if more than 8 (!) arrays were initialized).
>> See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
>> simple Lua script that triggers this Lua-5.3 bug and other details
>> about this bug.  I temporarily worked around the problem by using our
>> build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
>> in the absence of Lua5.1 or 5.2 our build system should just
>> cleanly drop the Lua PLplot component and continue).
>> 
>> Please try that simple Lua script to see whether the Fedora version of
>> Lua-5.3 also has this severe bug.  If you do confirm, then that is
>> pretty good evidence it is a general Lua-5.3 bug (rather than just
>> Debian related), and in this case I would be willing to take this
>> issue to the Lua developers rather than waiting for some response to
>> my bug report from the Debian packagers.
>> 
>> It appears from
>> <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
>> the blacklisting worked without actual build issues (as expected), but
>> the actual error you get is because your rpm logic is expecting Lua
>> files from PLplot that are not there because of the blacklisting.  So
>> your response to this issue likely depends on whether you can get the
>> above simple test script to work for Fedora's version of Lua5.3.  If
>> that test actually works for Fedora, then it appears the Lua5.3 issue
>> is simply a Debian packaging issue that has nothing to do with Fedora,
>> and you should edit cmake/modules/lua.cmake to make the slight change
>> to look first for 5.3, then 5.2, then 5.1.  However, if that test also
>> fails for you, and you think the upstream Lua5.3 fix is going to take
>> a while to get fixed, then you should change your rpm logic to drop
>> all the expected Lua results.
>> 
>> Alan
>
> I replied to the debian bug.  It appears that lua 5.3.5 on Fedora rawhide is 
> fine.

See my further traffic there.

In any case I was coming around to the view that our build system
should not blacklist Lua5.3 since the issue I observe is a run-time
issue, i.e., it does not affect builds or generation of a binary deb
or rpm.  But now this conclusion is even stronger when it appears from
your Fedora results it is fairly likely the run-time issue is confined
just to Debian.

Therefore I have changed (see commit caf4801df) the Lua find logic so
if the user requests a certain version of Lua our build system will
attempt to find it, but otherwise the latest installed version of Lua
will be found.

Please try building an RPM again using this commit.

Alan
__________________________
Alan W. Irwin

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 now working well with Debian Buster + release timing

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

On 09/20/2018 12:22 AM, Alan W. Irwin wrote:
> On 2018-09-19 22:06-0600 Orion Poplawski wrote:
> 
>> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>>> To Orion and Ole:
>>>
>>> Commit a730ebe34 has removed the last of the "new software" issues I
>>> have identified with Debian Testing = Buster.
>>>
>>> @Orion: I encourage you to try that commit on Fedora to see if you get
>>> similarly good results for all Linux-available components of
>>> PLplot for that other cutting-edge Linux platform.
>>>
>>> @Both: You both also might want to experiment with this commit as the
>>> basis for much-improved PLplot packages for Fedora and Debian.
>>> However such packages can only be considered preliminary until PLplot
>>> makes an official release.  What I can say on that topic is commit
>>> a730ebe34 is an important milestone on the trail to the next release,
>>> but we are not there yet.
>>>
>>> For example, the CMake test that is automatically produced every night
>>> by my computer for the CMake developers builds and tests the latest
>>> CMake.  One of those tests is the PLplot contract test which tests
>>> whether a build (but not test) of PLplot is successful.  That test is
>>> formally succeeding, but those PLplot builds are incomplete (with the
>>> cairo device driver dropped) because of incompatibilities with the way
>>> we configure our cairo device driver using internal details of the
>>> CMake pkg-config capability.  Although the use of such internal
>>> details has worked well over many years with few adjustments needed
>>> for changes to those internal details with CMake version, it is again
>>> no longer working with the very latest CMake.  This reflects the
>>> fundamental fragility of any method that uses internal details.
>>> Therefore, to deal with this issue my plan is to completely rewrite
>>> our support for the cairo device using the official CMake pkg-config
>>> support rather than internal details of that support.  And there are
>>> also a few other topics I would like to squeeze into the next release.
>>> So this makes the ETA of our next PLplot release still somewhat
>>> uncertain, but I am still hoping to get it done this year (before
>>> Christmas season) rather than early next year.
>>
>> Latest git (a9d9500c) built on Fedora Rawhide:
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>>
>> Despite the overall failure to build, looks mostly okay, but it 
>> appears that you don't support lua 5.3:
>>
>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>> version "5.2")
>> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
>> version "5.1")
>> -- LUA_INCLUDE_DIR =
>> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
>> -- WARNING: Lua header and/or library not found. Disabling Lua binding
> 
> Hi Orion:
> 
> Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
> for all but one example, but that one example exposed a Lua-5.3 bug
> (at least for the Debian version of Lua5.3) that was severe
> (arithmetic quit working if more than 8 (!) arrays were initialized).
> See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
> simple Lua script that triggers this Lua-5.3 bug and other details
> about this bug.  I temporarily worked around the problem by using our
> build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
> in the absence of Lua5.1 or 5.2 our build system should just
> cleanly drop the Lua PLplot component and continue).
> 
> Please try that simple Lua script to see whether the Fedora version of
> Lua-5.3 also has this severe bug.  If you do confirm, then that is
> pretty good evidence it is a general Lua-5.3 bug (rather than just
> Debian related), and in this case I would be willing to take this
> issue to the Lua developers rather than waiting for some response to
> my bug report from the Debian packagers.
> 
> It appears from
> <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
> the blacklisting worked without actual build issues (as expected), but
> the actual error you get is because your rpm logic is expecting Lua
> files from PLplot that are not there because of the blacklisting.  So
> your response to this issue likely depends on whether you can get the
> above simple test script to work for Fedora's version of Lua5.3.  If
> that test actually works for Fedora, then it appears the Lua5.3 issue
> is simply a Debian packaging issue that has nothing to do with Fedora,
> and you should edit cmake/modules/lua.cmake to make the slight change
> to look first for 5.3, then 5.2, then 5.1.  However, if that test also
> fails for you, and you think the upstream Lua5.3 fix is going to take
> a while to get fixed, then you should change your rpm logic to drop
> all the expected Lua results.
> 
> Alan

I replied to the debian bug.  It appears that lua 5.3.5 on Fedora 
rawhide is fine.


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

Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

[Ole S. <deb...@li...>]

Hi Alan,

I am very happy to read this, however I am currently stuck with a
problem that I can't build the package due to a problem in octave
<https://bugs.debian.org/906047> which is still unresolved in
unstable. Once this is fixed, I will upload a new package.

Thank you very much for your efforts!

Best

Ole

"Alan W. Irwin" <Ala...@gm...> writes:

> To Orion and Ole:
>
> Commit a730ebe34 has removed the last of the "new software" issues I
> have identified with Debian Testing = Buster.
>
> @Orion: I encourage you to try that commit on Fedora to see if you get
> similarly good results for all Linux-available components of
> PLplot for that other cutting-edge Linux platform.
>
> @Both: You both also might want to experiment with this commit as the
> basis for much-improved PLplot packages for Fedora and Debian.
> However such packages can only be considered preliminary until PLplot
> makes an official release.  What I can say on that topic is commit
> a730ebe34 is an important milestone on the trail to the next release,
> but we are not there yet.
>
> For example, the CMake test that is automatically produced every night
> by my computer for the CMake developers builds and tests the latest
> CMake.  One of those tests is the PLplot contract test which tests
> whether a build (but not test) of PLplot is successful.  That test is
> formally succeeding, but those PLplot builds are incomplete (with the
> cairo device driver dropped) because of incompatibilities with the way
> we configure our cairo device driver using internal details of the
> CMake pkg-config capability.  Although the use of such internal
> details has worked well over many years with few adjustments needed
> for changes to those internal details with CMake version, it is again
> no longer working with the very latest CMake.  This reflects the
> fundamental fragility of any method that uses internal details.
> Therefore, to deal with this issue my plan is to completely rewrite
> our support for the cairo device using the official CMake pkg-config
> support rather than internal details of that support.  And there are
> also a few other topics I would like to squeeze into the next release.
> So this makes the ETA of our next PLplot release still somewhat
> uncertain, but I am still hoping to get it done this year (before
> Christmas season) rather than early next year.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

On 2018-09-19 22:06-0600 Orion Poplawski wrote:

> On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
>> To Orion and Ole:
>> 
>> Commit a730ebe34 has removed the last of the "new software" issues I
>> have identified with Debian Testing = Buster.
>> 
>> @Orion: I encourage you to try that commit on Fedora to see if you get
>> similarly good results for all Linux-available components of
>> PLplot for that other cutting-edge Linux platform.
>> 
>> @Both: You both also might want to experiment with this commit as the
>> basis for much-improved PLplot packages for Fedora and Debian.
>> However such packages can only be considered preliminary until PLplot
>> makes an official release.  What I can say on that topic is commit
>> a730ebe34 is an important milestone on the trail to the next release,
>> but we are not there yet.
>> 
>> For example, the CMake test that is automatically produced every night
>> by my computer for the CMake developers builds and tests the latest
>> CMake.  One of those tests is the PLplot contract test which tests
>> whether a build (but not test) of PLplot is successful.  That test is
>> formally succeeding, but those PLplot builds are incomplete (with the
>> cairo device driver dropped) because of incompatibilities with the way
>> we configure our cairo device driver using internal details of the
>> CMake pkg-config capability.  Although the use of such internal
>> details has worked well over many years with few adjustments needed
>> for changes to those internal details with CMake version, it is again
>> no longer working with the very latest CMake.  This reflects the
>> fundamental fragility of any method that uses internal details.
>> Therefore, to deal with this issue my plan is to completely rewrite
>> our support for the cairo device using the official CMake pkg-config
>> support rather than internal details of that support.  And there are
>> also a few other topics I would like to squeeze into the next release.
>> So this makes the ETA of our next PLplot release still somewhat
>> uncertain, but I am still hoping to get it done this year (before
>> Christmas season) rather than early next year.
>
> Latest git (a9d9500c) built on Fedora Rawhide:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905
>
> Despite the overall failure to build, looks mostly okay, but it appears that 
> you don't support lua 5.3:
>
> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version 
> "5.2")
> -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version 
> "5.1")
> -- LUA_INCLUDE_DIR =
> -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
> -- WARNING: Lua header and/or library not found. Disabling Lua binding

Hi Orion:

Thanks for that feedback.  Lua5.3 worked here (Debian Testing = Buster)
for all but one example, but that one example exposed a Lua-5.3 bug
(at least for the Debian version of Lua5.3) that was severe
(arithmetic quit working if more than 8 (!) arrays were initialized).
See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a
simple Lua script that triggers this Lua-5.3 bug and other details
about this bug.  I temporarily worked around the problem by using our
build system to blacklist Lua-5.3 until this bug is fixed (i.e.,
in the absence of Lua5.1 or 5.2 our build system should just
cleanly drop the Lua PLplot component and continue).

Please try that simple Lua script to see whether the Fedora version of
Lua-5.3 also has this severe bug.  If you do confirm, then that is
pretty good evidence it is a general Lua-5.3 bug (rather than just
Debian related), and in this case I would be willing to take this
issue to the Lua developers rather than waiting for some response to
my bug report from the Debian packagers.

It appears from
<https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log>
the blacklisting worked without actual build issues (as expected), but
the actual error you get is because your rpm logic is expecting Lua
files from PLplot that are not there because of the blacklisting.  So
your response to this issue likely depends on whether you can get the
above simple test script to work for Fedora's version of Lua5.3.  If
that test actually works for Fedora, then it appears the Lua5.3 issue
is simply a Debian packaging issue that has nothing to do with Fedora,
and you should edit cmake/modules/lua.cmake to make the slight change
to look first for 5.3, then 5.2, then 5.1.  However, if that test also
fails for you, and you think the upstream Lua5.3 fix is going to take
a while to get fixed, then you should change your rpm logic to drop
all the expected Lua results.

Alan
__________________________
Alan W. Irwin

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 now working well with Debian Buster + release timing

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

On 09/15/2018 01:49 PM, Alan W. Irwin wrote:
> To Orion and Ole:
> 
> Commit a730ebe34 has removed the last of the "new software" issues I
> have identified with Debian Testing = Buster.
> 
> @Orion: I encourage you to try that commit on Fedora to see if you get
> similarly good results for all Linux-available components of
> PLplot for that other cutting-edge Linux platform.
> 
> @Both: You both also might want to experiment with this commit as the
> basis for much-improved PLplot packages for Fedora and Debian.
> However such packages can only be considered preliminary until PLplot
> makes an official release.  What I can say on that topic is commit
> a730ebe34 is an important milestone on the trail to the next release,
> but we are not there yet.
> 
> For example, the CMake test that is automatically produced every night
> by my computer for the CMake developers builds and tests the latest
> CMake.  One of those tests is the PLplot contract test which tests
> whether a build (but not test) of PLplot is successful.  That test is
> formally succeeding, but those PLplot builds are incomplete (with the
> cairo device driver dropped) because of incompatibilities with the way
> we configure our cairo device driver using internal details of the
> CMake pkg-config capability.  Although the use of such internal
> details has worked well over many years with few adjustments needed
> for changes to those internal details with CMake version, it is again
> no longer working with the very latest CMake.  This reflects the
> fundamental fragility of any method that uses internal details.
> Therefore, to deal with this issue my plan is to completely rewrite
> our support for the cairo device using the official CMake pkg-config
> support rather than internal details of that support.  And there are
> also a few other topics I would like to squeeze into the next release.
> So this makes the ETA of our next PLplot release still somewhat
> uncertain, but I am still hoping to get it done this year (before
> Christmas season) rather than early next year.

Latest git (a9d9500c) built on Fedora Rawhide:

https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905

Despite the overall failure to build, looks mostly okay, but it appears 
that you don't support lua 5.3:

-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
version "5.2")
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact 
version "5.1")
-- LUA_INCLUDE_DIR =
-- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so
-- WARNING: Lua header and/or library not found. Disabling Lua binding


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

Re: [Plplot-devel] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
>
> By the way, it is a bit of a concern for the Cygwin rolling release that the CMake,
> gcc, and gnat versions are getting pretty far behind what is available with MinGW-
> w64/MSYS2, but, of course, those packaging delays could all be special cases.
> Does the overall health of the Cygwin project seem fine (e.g., all legitimate
> questions answered in a timely way by Cygwin developers, and packaging progress
> continuing to be made for a large number of packages) from what you have been
> reading on the Cygwin mailing list?
>
The Cygwin mailing list is actively used for both announcements of updates to packages (many of which I do not use myself, but that is another matter) and to answer questions and solve problems. In that respect the whole project seems healthy enough. That said, I have seen several questions about packages like CMake lagging behind the developments and not all questions get answered properly. Perhaps it does not hurt to ask about the plans regarding the packages we are interested in in the context of PLplot.

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] Plplot now working well with Debian Buster + release timing

[Alan W. I. <Ala...@gm...>]

To Orion and Ole:

Commit a730ebe34 has removed the last of the "new software" issues I
have identified with Debian Testing = Buster.

@Orion: I encourage you to try that commit on Fedora to see if you get
similarly good results for all Linux-available components of
PLplot for that other cutting-edge Linux platform.

@Both: You both also might want to experiment with this commit as the
basis for much-improved PLplot packages for Fedora and Debian.
However such packages can only be considered preliminary until PLplot
makes an official release.  What I can say on that topic is commit
a730ebe34 is an important milestone on the trail to the next release,
but we are not there yet.

For example, the CMake test that is automatically produced every night
by my computer for the CMake developers builds and tests the latest
CMake.  One of those tests is the PLplot contract test which tests
whether a build (but not test) of PLplot is successful.  That test is
formally succeeding, but those PLplot builds are incomplete (with the
cairo device driver dropped) because of incompatibilities with the way
we configure our cairo device driver using internal details of the
CMake pkg-config capability.  Although the use of such internal
details has worked well over many years with few adjustments needed
for changes to those internal details with CMake version, it is again
no longer working with the very latest CMake.  This reflects the
fundamental fragility of any method that uses internal details.
Therefore, to deal with this issue my plan is to completely rewrite
our support for the cairo device using the official CMake pkg-config
support rather than internal details of that support.  And there are
also a few other topics I would like to squeeze into the next release.
So this makes the ETA of our next PLplot release still somewhat
uncertain, but I am still hoping to get it done this year (before
Christmas season) rather than early next year.

Alan
__________________________
Alan W. Irwin

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] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)

[Alan W. I. <Ala...@gm...>]

On 2018-09-14 12:19-0000 Arjen Markus wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:Ala...@gm...]
>> To Jerry and Arjen:
>>
>> On Sunday (just before commit 7ec926fae) I discovered that my installs of gdc-7
>> and gnat-7 were probably not good choices because although I had both gcc-7 and
>> gcc-8 installed, PLplot was being built with gcc-8 rather than gcc-7 on my Debian
>> Buster system.  So in this case at least Debian does not have tight version
>> consistency requirements between either gdc or gnat and gcc.  And perhaps that is
>> justified since previously I was getting perfect results with the combination of gdc-7
>> and gcc-8.
>> However, the above parallel build issue with gnat-7 encouraged me to try gnat-8,
>> and I decided to install gdc-8 as well just to be consistent with gcc-8.
>> It turns out (see the above commit message for the details) the combination of gdc-
>> 8, gnatmake-8, and gcc-8 produces perfect massively
>> (-j10) parallel build and test results
>> for a comprehensive set of of configurations and build trees, and for three different
>> CMake versions.
>>
>> So it seems once again that on Linux at least, parallel builds of our Ada bindings
>> and examples work well, and I advise on other platforms to avoid gnat-7 in all cases,
>> to use parallel builds with caution, and at least for the sake of consistency use the
>> same version of gdc, gnat, and gcc (e.g., gdc-8, gnat-8, and gcc-8).
>>
>
> I just checked the Cygwin set-up: there is at this moment at least no version 8 available within that environment. I do not know if there are any plans to incorporate it, but I will keep an eye out.

Indeed, from <https://cygwin.com/cgi-bin2/package-grep.cgi> a search
for gcc shows that currently the maximum gcc version available is
gcc-7 and similarly gnat-7 is the maximum version of gnat that is
available.  So you might want to try those two (in fact your previous
tests might have already been done with those two), but from my Linux
experience I would not bother with parallel builds with gnat-7.  But
as I recall, Cygwin has other troubles with parallel builds so that might
be a moot constraint.

In contrast to the Cygwin case, <http://repo.msys2.org/mingw/x86_64/>
shows for the MinGW-w64/MSYS2 case that the maximum gcc and gnat
versions are 8.2.0 which is also the versions of those two software
packages I used recently for my successful Debian Buster tests.  So
the next time you test this platform I suggest you try version 8 of
gcc and gnat if you are not doing that already.  And since parallel
builds and tests worked so well for the Linux case you might want to
try those on this platform especially if those have been successful
before.

By the way, it is a bit of a concern for the Cygwin rolling release
that the CMake, gcc, and gnat versions are getting pretty far behind
what is available with MinGW-w64/MSYS2, but, of course, those
packaging delays could all be special cases.  Does the overall health
of the Cygwin project seem fine (e.g., all legitimate questions
answered in a timely way by Cygwin developers, and packaging progress
continuing to be made for a large number of packages) from what you
have been reading on the Cygwin mailing list?

Alan
__________________________
Alan W. Irwin

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] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> To Jerry and Arjen:
>
> On Sunday (just before commit 7ec926fae) I discovered that my installs of gdc-7
> and gnat-7 were probably not good choices because although I had both gcc-7 and
> gcc-8 installed, PLplot was being built with gcc-8 rather than gcc-7 on my Debian
> Buster system.  So in this case at least Debian does not have tight version
> consistency requirements between either gdc or gnat and gcc.  And perhaps that is
> justified since previously I was getting perfect results with the combination of gdc-7
> and gcc-8.
> However, the above parallel build issue with gnat-7 encouraged me to try gnat-8,
> and I decided to install gdc-8 as well just to be consistent with gcc-8.
> It turns out (see the above commit message for the details) the combination of gdc-
> 8, gnatmake-8, and gcc-8 produces perfect massively
> (-j10) parallel build and test results
> for a comprehensive set of of configurations and build trees, and for three different
> CMake versions.
>
> So it seems once again that on Linux at least, parallel builds of our Ada bindings
> and examples work well, and I advise on other platforms to avoid gnat-7 in all cases,
> to use parallel builds with caution, and at least for the sake of consistency use the
> same version of gdc, gnat, and gcc (e.g., gdc-8, gnat-8, and gcc-8).
>

I just checked the Cygwin set-up: there is at this moment at least no version 8 available within that environment. I do not know if there are any plans to incorporate it, but I will keep an eye out.

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] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)

[Alan W. I. <Ala...@gm...>]

On 2018-07-16 10:10-0700 Alan W. Irwin wrote:

> On 2018-06-09 13:30-0700 Alan W. Irwin wrote:
>
>> On 2018-04-15 11:15-0700 Alan W. Irwin wrote:
>> 
>>> Hi Jerry:
>> [...]
>>> So once this Ada build issue appeared again for me yesterday after all
>>> those previous successful hardware checks, I did a google search for
>>> the terms (without the quotes) "gnatmake intermittent build error" and
>>> found
>>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
>>> which was a bug report in 2015 about intermittent Ada build issues
>>> which was immediately fixed back then.  However, my gnat version (=
>>> 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure
>>> at this stage that bug 65451 is the issue that is causing the
>>> intermittent Ada build issues for me. Therefore, I plan to use the
>>> -DENABLE_ada=OFF option for my further testing until I can get access
>>> to a later version of the Ada build tools myself, and I suggest others
>>> who currently don't have access to Ada build tools with bug 65451
>>> fixed should do the same.
>> 
>> Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that 
>> I
>> was using for Debian Jessie) the first test of Ada has been a complete 
>> success.
>> See commit 994723471 for the details of the tests I ran.
>
> Hi Jerry:
>
> I just ran into this issue for the first time for my new hardware and
> latest Ada/gnat (version 7.3.0) from Debian Buster (sigh).  I was
> doing a parallel build (with -j10 for my new system with 8 real
> cores), when the following error was encountered:
>
> ./plplot_standard.o: file not recognized: File truncated
> collect2: error: ld returned 1 exit status
> gnatlink-7: error when calling /usr/bin/gcc-7
> gnatmake: *** link failed.
> examples/ada/CMakeFiles/xstandard30a.dir/build.make:77: recipe for target 
> 'examples/ada/xstandard30a' failed
> make[3]: *** [examples/ada/xstandard30a] Error 4
>
> A google search found
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857831> which
> appears to be a similar (or the same bug) for 7.1.  At the time, the
> Debian packagers thought they had a fix, but it seems from my
> experience either that was not true or else the fix has not been
> propagated to 7.3. I have just now privately reported the situation to
> Matthias Klose (the author of the bug 857831 report, and they guy who
> decided that bug was fixed), and we will see what he says.  But to
> work around this problem until it is fixed for Debian Buster, I plan
> to use -DENABLE_ada=OFF for my testing.
>

To Jerry and Arjen:

On Sunday (just before commit 7ec926fae) I discovered that my installs
of gdc-7 and gnat-7 were probably not good choices because although I
had both gcc-7 and gcc-8 installed, PLplot was being built with gcc-8
rather than gcc-7 on my Debian Buster system.  So in this case at
least Debian does not have tight version consistency requirements
between either gdc or gnat and gcc.  And perhaps that is justified
since previously I was
getting perfect results with the combination of gdc-7 and gcc-8.
However, the above parallel build issue with gnat-7 encouraged me to try gnat-8, and
I decided to install gdc-8 as well just to be consistent with gcc-8.
It turns out (see the above commit message for the details) the
combination of gdc-8, gnatmake-8, and gcc-8 produces perfect massively
(-j10) parallel build and test results
for a comprehensive set of of configurations and build trees, and for
three different CMake versions.

So it seems once again that on Linux at least, parallel builds of our
Ada bindings and examples work well, and I advise on other platforms
to avoid gnat-7 in all cases, to use parallel builds with caution, and
at least for the sake of consistency use the same version of gdc,
gnat, and gcc (e.g., gdc-8, gnat-8, and gcc-8).

Alan
__________________________
Alan W. Irwin

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] Recent bump of CMake minimum version

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

Hi Alan,
Thanks for this warning - I will have to see then how the building of CMake goes ...
Regards,
Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Sunday, September 09, 2018 1:19 PM
> To: Arjen Markus; PLplot development list
> Subject: Recent bump of CMake minimum version
>
> Hi Arjen:
>
> For your information I have recently obtained perfect (no configure, build, or install
> issues, and perfect PostScript difference reports) comprehensive test results for the
> noninteractive case for CMake versions 3.7.2, 3.11.0, and 3.12.2.  I have also
> bumped the CMake minimum version from 3.6.2 for all platforms to 3.7.2 for the
> Linux platform and 3.11.0 for all other platforms.  The principal positive impact of
> this change is to reduce our exposure to bugs which occur in older CMake versions
> (especially for non-Linux platforms).  But for Cygwin users like you, the negative
> impact of this change is that you will have to build your own CMake with version >=
> 3.11.0 before you can build PLplot.  I am sorry about that inconvenience for you
> and other Cygwin users, but this situation is due to the CMake package on Cygwin
> being unmaintained since the date some time ago when CMake version 3.6.2 was
> released.  So perhaps the way to resolve this issue is to volunteer on the Cygwin
> list to maintain that Cygwin CMake package yourself?
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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] Recent bump of CMake minimum version

[Alan W. I. <Ala...@gm...>]

Hi Arjen:

For your information I have recently obtained perfect (no configure,
build, or install issues, and perfect PostScript difference reports)
comprehensive test results for the noninteractive case for CMake
versions 3.7.2, 3.11.0, and 3.12.2.  I have also bumped the CMake
minimum version from 3.6.2 for all platforms to 3.7.2 for the Linux
platform and 3.11.0 for all other platforms.  The principal positive
impact of this change is to reduce our exposure to bugs which occur in
older CMake versions (especially for non-Linux platforms).  But for
Cygwin users like you, the negative impact of this change is that you
will have to build your own CMake with version >= 3.11.0 before you
can build PLplot.  I am sorry about that inconvenience for you and
other Cygwin users, but this situation is due to the CMake package on
Cygwin being unmaintained since the date some time ago when CMake
version 3.6.2 was released.  So perhaps the way to resolve this issue
is to volunteer on the Cygwin list to maintain that Cygwin CMake
package yourself?

Alan
__________________________
Alan W. Irwin

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] Installed version of PLplot working again!

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Monday, August 27, 2018 3:26 AM
> To: PLplot development list
> Subject: [Plplot-devel] Installed version of PLplot working again!
>
> As of commit e298aa70a, the installed version of PLplot works again after a long
> time (since early April) where it did not work.

Congratulations on completing this work - from the commit message I understand that you have had to deal with a plethora of details not all of which are obvious or trivial.

The fact that the installation is working again seems a good opportunity to turn your attention to this thread in comp.lang.fortran: https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/N_tU-hVJEt0

We considered offering a binary version a long time ago, but never settled on a useful solution. Reading (and participating in) this thread I think this might be a good time to think about it again. Of course this adds a burden to the maintenance, but perhaps we can come up with a minimal but still useable and useful binary installation - perhaps merely to see how many people are interested in such a ready-made package. I will give the matter some serious thought.

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] Installed version of PLplot working again!

[Alan W. I. <Ala...@gm...>]

As of commit e298aa70a, the installed version of PLplot works again
after a long time (since early April) where it did not work.  This
commit completes a project to implement a highly recommended
modernization of our build system (i.e., to use a namespaced prefix
(of "PLPLOT::") for every target that is installed.  This commit
also solves some further "modern software" PLplot bugs that occur
for Debian Buster versions of free software libraries.

Preliminary work on this project started in March.  Although the
build-tree version of PLPlot worked throughout this time, my apologies
for the long down-time for the installed version of PLplot caused by
(1) the distraction of replacing my computer right in the middle of
this project and (2) dealing with the quite large number of "new
software" version issues caused by upgrading my software from Debian
Jessie to Debian Buster right in the middle of this project.

I got an unconstrained (i.e., virtually complete with both interactive
and noninteractive tests for both the core build tree and installed
examples trees for our three principal library/driver configurations)
comprehensive test of PLplot to work for me for Debian Buster so
I encourage you to make such a comprehensive test yourselves (likely with
"--do_test_interactive no" initially to save yourselves quite a bit of
"baby-sitting" to get through the test) and let me know of any issues
you find.

This good comprehensive test result for Debian Buster has some caveats.

* intermittent (UGH) plmeta error

There was an error concerning an attempted *interactive* test on the
(confirmed) disabled plmeta device for the CMake-based build system
for the installed examples.  Such tests should not occur because the
device is disabled and especially not for interactive tests since it
is a noninteractive device!  However, since that error was a
showstopper for that component of the overall comprehensive test, I
have confirmed all our device numbers were unique (see the above
commit message for details) to make sure no other device was being
misidentified as plmeta.  Furthermore, I have been completely unable
to trigger that error again with two similar comprehensive tests (one
parallel, one not) focussing on just that one component.  And also for one
exactly identical comprehensive test (parallel and for all
components).  So my plan is to wait until this nasty error triggers
again (if it ever does) and look deeper at it then.  So if you see
any "plmeta" testing issues in the near future for
the default case where plmeta is disabled, please let me know!

* Modern (Debian Buster) software bugs

   + Modern Ada gnatmake (version 7.3.0-2) has a bug where parallel
     builds don't work properly.  There is no way I want to give up the
     huge speed advantage of parallel builds so I have worked around
     this bug by disabling Ada for the above test.  I have made an
     unoffical query about this return of parallel gnatmake issues to
     Debian with no response so far so it is time to escalate this to
     an official Debian bug report and likely an official upstream
     gnatmake bug report as well.

   + Modern Lua 5.3.3 has a bug where if more than a modest number of
     arrays are initialized all arithmetic starts failing!  Only
     example 23 in the set of Lua examples exposes this bug so I have
     worked around the issue by temporarily dropping that example from
     the Lua tests.  I have reported this issue with a simple
     (completely independent of PLplot) test Lua script demonstrating
     this Lua issue as an official Debian bug report, but there has
     been no response so it is past time to take this upstream to the
     Lua developers.

   + Our extXdrawable_demo application is written for the ancient GTK+
     version 2 case and needs to be rewritten for the (modern) GTK+
     version 3 case.  Jonathan Woithe has kindly volunteered to do that
     rewrite, but until he completes his work, I have worked around the
     issue by disabling this example.

* Modern (Debian Buster) software warnings

   + OCaml build warnings

     These seem fairly innocuous, but this is a Debian Buster versus
     Debian Jessie regression that I need to investigate further.

   + I am now getting undefined symbol warnings from "ldd -r" tests
     done by the above script run.  These issues did not cause any
     obvious errors, but this is a Debian Buster versus Debian Jessie
     regression that I need to investigate further.

Now that the installed version of PLplot is largely working again and
both build-tree and install-tree PLplot more or less working for a
system (Debian Buster) with near cutting-edge software versions, I am
beginning to consider making a PLplot release.  My current plan is to
push quite a few further topics (all of them much shorter than the
present topic that was just finished) before that release which would
likely delay the release until at least December or possibly into
early 2019.  However, if someone here has a strong preference for an
earlier release than that sort of time scale, I would certainly be
willing to consider that possibility by dropping some of the topics
I want to work on before the release.

Alan
__________________________
Alan W. Irwin

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] Status of our octave binding and examples for version 4.4.0 of octave

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Monday, August 13, 2018 9:56 PM
> To: Arjen Markus
> Cc: Orion Poplawski; PLplot development list
> Subject: RE: Status of our octave binding and examples for version 4.4.0 of octave
>
>
> Let's ignore octave for a bit and look at the more general picture.
> If you like the goal (in its own right) of learning to build packages for the MinGW-
> w64/MSYS2 platform, then I suggest you follow the package build documentation
> examples under the heading "Re-building a package" at
> <https://github.com/msys2/msys2/wiki/Creating-packages>.
> Can you use those steps to build both their examples (flex and python3)?  If not,
> then you should take the problem to the MSYS2 mailing list to get help with that
> documentation.  But if that general procedure works for you, then the next obvious
> step is to help out with the PLplot packaging at
> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-plplot>
> by first building that package as is, fixing it according to your own experience (e.g.,
> by moving to Python 3, and by enabling qt), and drawing Alex's attention to your
> improvements (likely via a pull
> request) so they will be made part of the official Plplot package for this platform.
>
I can certainly try ...

> Moving back to the octave case, I am pretty sure unless that semi-official package
> is completely broken, that the same procedures used to build flex, python3, and
> PLplot should also work fine for octave without all the issues you encountered
> above.  Assuming you can build that octave package, then the next steps would be
> to evaluate the result for our needs, and assuming it does work for those needs (or
> can easily be fixed), advocate making it an official package that the PLplot package
> depends on.
>
> > I guess an alternative could be to simply build Octave and install it without
> pacman, but I have not tried that yet.
>
> I would advise against that since unofficial octave builds are not going to help our
> octave users that much on this particular platform and may turn out to be a black
> hole sucking up a lot of your time.
> Instead, I think it would be better in the long-run to help get an official octave
> package running for this platform as I have outlined above.
>

Last night I tried to build Octave out of the box, as the computer would do most of the work - run configure, make, make install ... However, the make step fails:

  CXX      libinterp/corefcn/libinterp_corefcn_libcorefcn_la-pr-output.lo
libinterp/corefcn/pr-output.cc: In function 'float_display_format make_format(const T&) [with T = intNDArray<octave_int<signed char> >]':
libinterp/corefcn/pr-output.cc:1736:59: error: call of overloaded 'abs(signed char)' is ambiguous
           (std::floor (log10 (double (abs (nda(i).value ()))) + 1));  \
                                                           ^
libinterp/corefcn/pr-output.cc:1748:1: note: in expansion of macro 'MAKE_INT_MATRIX_FORMAT'
 MAKE_INT_MATRIX_FORMAT (octave_int8)
 ^~~~~~~~~~~~~~~~~~~~~~
In file included from C:/msys64/mingw64/include/c++/6.2.0/cmath:45:0,
                 from libinterp/corefcn/pr-output.cc:27:
C:/msys64/mingw64/x86_64-w64-mingw32/include/math.h:254:15: note: candidate: int abs(int)
   int __cdecl abs(int _X);
               ^~~
In file included from C:/msys64/mingw64/include/c++/6.2.0/ext/string_conversions.h:41:0,
                 from C:/msys64/mingw64/include/c++/6.2.0/bits/basic_string.h:5402,
                 from C:/msys64/mingw64/include/c++/6.2.0/string:52,
                 from C:/msys64/mingw64/include/c++/6.2.0/bits/locale_classes.h:40,
                 from C:/msys64/mingw64/include/c++/6.2.0/bits/ios_base.h:41,
                 from C:/msys64/mingw64/include/c++/6.2.0/iomanip:40,
                 from libinterp/corefcn/pr-output.cc:29:
C:/msys64/mingw64/include/c++/6.2.0/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
   abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
   ^~~
C:/msys64/mingw64/include/c++/6.2.0/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
... (a lot more complaints)

So that is the end of that road as well as far as I am concerned.

It would seem that the only way we can proceed is indeed by obtaining an official Octave package, as you indicate.

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.