plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, July 04, 2017 12:30 AM
>
> Hi Arjen:
>
> Congratulations on this success after a number of iterations between us. It is a
> great feeling to not have this uncertainty hanging over us.
>
Most definitely :)

> If your MinGW-w64/MSYS and MSVC follow ups (see below) show no wxwidgets
> problems of any urgent kind on those platforms, then I intend to disable the CMake
> PL_WXWIDGETS_IPC3 option by forcing it to ON, (the default option you just
> tested) on all platforms for the
> 5.13.0 release with the further plan later (if experience through a couple of releases
> shows no problems with that disabling) to remove this CMake
> PL_WXWIDGETS_IPC3 option (and also the large amount of code associated with
> when the C++ macro PL_WXWIDGETS_IPC3 is _not_ #defined).
>
> To answer your question above, now that you have had this success, I would
> appreciate you doing the following:
>
> 1. Run (all on one line rather than mail wrapped)
>
> scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
> --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -
> DENABLE_cxx=ON"
> --build_command make --ctest_command ctest --do_test_noninteractive no --
> do_ctest no --do_nondynamic no --do_static no --do_test_install_tree no --
> do_test_traditional_install_tree no
>
> on the MinGW-w64/MSYS2 platform.

I will do that tonight.

>
> 2. Do a simple test of wxwidgets on MSVC
>

Ah, I tried it yesterday, but my wxWidgets installation was not recognised, despite the hints I gave (the FindWxWidgets.cmake file documents a few variables that you can use). I have studied the find method, added a bunch of debug statements to see what is going on, but sofar I have failed to make any progress. (Note: The code is five or six pages long!)

> 3. If 2. works, then run the above comprehensive test (presumably with NMake
> Makefiles
> generator) on the MSVC platform (+ MinGW-w64/MSYS2 Unix tools on the PATH
> like what worked before for your noninteractive MSVC comprehensive test).  I
> would stick with the suggested constraints to start, and then if all is well extend the
> test further as discussed above.
>
> 3 obviously should come some time after 2, but otherwise I don't care strongly
> about the order of these tests so long as they are all done (since they are all
> important).
>
> In any case, please commit your setup scripts (bash scripts where you set
> environment variables and run scripts/comprehensive_test.sh) for each kind of
> comprehensive test you want to run for any given platform).  Probably, the best
> place to commit those scripts is in newly created directories for each platform, e.g.,
> scripts/setup/linux (which I plan to populate soon), scripts/setup/mingw_msys
> (which I also plan to populate soon), scripts/setup/mingw_w64_msys2, and
> scripts/setups/msvc_nmake. Those setup scripts should have a tailored section
> which contains all the idiosyncrasies of your particular personal platform (e.g.,
> directory prefix locations that would need to be changed by other users.  For an
> example of this approach please take a look at, e.g., scripts/setup/mingw_msys
> files once I populate those files with what I did recently in the Wine/MINGW/MSYS
> case. Such setup scripts allow us to replicate and document exactly how we launch
> our comprehensive tests. They should also help other users in general with setting
> up builds and tests of PLplot on the various platforms.
>
Souds useful indeed, although it is tempting to try and make them less idiosyncratic. I do have a bunch of such scripts, so populating the directories you suggest ought not to be too difficult. I do lack time this week and this weekend to do much about it. Next week provides better oportunities.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-07-03 18:22-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Saturday, July 01, 2017 11:08 PM
>>
>> After reviewing the code, I spotted a fundamental error in the Windows variant of
>> the three-semaphores case which is that code used three Windows mutexes rather
>> than three named Windows semaphores.
>> [...] Therefore, I have now (commit b779495) addressed this issue by using
>> named Windows semaphores in the Windows variant of the three semaphores
>> approach, but I cannot even build test this modified Windows variant of the three-
>> semaphores approach here. So I need you to do that.
>

> I rebuilt PLplot using this latest commit and it all worked fine :).
   So the three-semaphores approach you have now implemented was the
   right way. I will try and see whether I can get the same result with
   the MSVC compiler.

>
>>
>> To be specific about what test I want you to run, please freshly configure PLplot
>> with the -DPLPLOT_WX_DEBUG_OUTPUT=ON option (which adds lots of useful
>> information if there are any remaining errors with the three-semaphores approach).
>>
> Unless you think this is necessary, given the completely positive results, I will concentrate on MSVC.

Hi Arjen:

Congratulations on this success after a number of iterations between
us. It is a great feeling to not have this uncertainty hanging over
us.

If your MinGW-w64/MSYS and MSVC follow ups (see below) show no
wxwidgets problems of any urgent kind on those platforms, then I
intend to disable the CMake PL_WXWIDGETS_IPC3 option by forcing it to
ON, (the default option you just tested) on all platforms for the
5.13.0 release with the further plan later (if experience through a
couple of releases shows no problems with that disabling) to remove
this CMake PL_WXWIDGETS_IPC3 option (and also the large amount of code
associated with when the C++ macro PL_WXWIDGETS_IPC3 is _not_
#defined).

To answer your question above, now that you have had this success, I
would appreciate you doing the following:

1. Run (all on one line rather than mail wrapped)

scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
--cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON"
--build_command make --ctest_command ctest 
--do_test_noninteractive no --do_ctest no 
--do_nondynamic no --do_static no 
--do_test_install_tree no --do_test_traditional_install_tree no

on the MinGW-w64/MSYS2 platform.  The cmake_added_options value limits
this comprehensive test to just the wxwidgets components of PLplot.
Those last 4 options limit the test to shared library only (to reduce
the testing time by a factor of three) and build-tree only (to reduce
the testing time by another factor of three).  But if that script run
is a success, and a nine-times longer run would not take too much of
your time compared to the other noninteractive comprehensive tests you
need to complete, then I would also suggest you extend the test by
dropping the last 4 options (or changing their values from no to yes)
to check all is well for the nondynamic and static cases and for the
two kinds of build systems for the install tree.

2. Do a simple test of wxwidgets on MSVC

3. If 2. works, then run the above comprehensive test (presumably with NMake Makefiles
generator) on the MSVC platform (+ MinGW-w64/MSYS2 Unix tools on the
PATH like what worked before for your noninteractive MSVC
comprehensive test).  I would stick with the suggested constraints
to start, and then if all is well extend the test further as discussed
above.

3 obviously should come some time after 2, but otherwise I don't care
strongly about the order of these tests so long as they are all done
(since they are all important).

In any case, please commit your setup scripts (bash scripts where you
set environment variables and run scripts/comprehensive_test.sh) for
each kind of comprehensive test you want to run for any given
platform).  Probably, the best place to commit those scripts is in
newly created directories for each platform, e.g., scripts/setup/linux
(which I plan to populate soon), scripts/setup/mingw_msys (which I
also plan to populate soon), scripts/setup/mingw_w64_msys2, and
scripts/setups/msvc_nmake. Those setup scripts should have a tailored
section which contains all the idiosyncrasies of your particular
personal platform (e.g., directory prefix locations that would need to
be changed by other users.  For an example of this approach please
take a look at, e.g., scripts/setup/mingw_msys files once I populate
those files with what I did recently in the Wine/MINGW/MSYS case. Such
setup scripts allow us to replicate and document exactly how we launch
our comprehensive tests. They should also help other users in general 
with setting up builds and tests of PLplot on the various platforms.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Planning for the release of 5.13.0

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

On 2017-07-03 13:54-0700 Alan W. Irwin wrote:

> * Completely debug the Windows variant of the 3-semaphores approach to
>  IPC between -dev wxwidgets and wxPLViewer.
>
>  The status of this project is Arjen and I have gone through a number
>  of iterations of code changes on my part and tests on his part, and
>  Arjen still needs to test my latest fix which makes the Windows
>  variant virtually identical to the POSIX variant of this code.
>  Thus, given that the POSIX version gives good results on Linux there
>  is a reasonable chance that we are done at this point with the code
>  fixes, but we won't know until Arjen tests the current code.

Obviously I forgot to look at incoming e-mail before sending the above.
I am now very happy to say that Arjen has now had good success
with a simple test of that updated code on MinGW-w64/MSYS2.  Congratulations,
Arjen for that nice breakthrough!  That good result removes quite a bit of
the uncertainty in the timing of our next release.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] Planning for the release of 5.13.0

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

We have made lots of progress (see our git log) since the release of
5.12.0 so I am looking forward to releasing 5.13.0 in the near future
(i.e., in July or August depending on how much time Arjen has for
PLplot this month).

N.B. Please let me know if you would like to squeeze something in
before the code freeze for that release.

The projects that I am aware of are that should likely be finished
before this release are the following (in decreasing order of
importance) with the first three considered more release-critical and the
last two considered less release critical:

* Completely debug the Windows variant of the 3-semaphores approach to
   IPC between -dev wxwidgets and wxPLViewer.

   The status of this project is Arjen and I have gone through a number
   of iterations of code changes on my part and tests on his part, and
   Arjen still needs to test my latest fix which makes the Windows
   variant virtually identical to the POSIX variant of this code.
   Thus, given that the POSIX version gives good results on Linux there
   is a reasonable chance that we are done at this point with the code
   fixes, but we won't know until Arjen tests the current code.

* Comprehensive tests on the Linux, MinGW-w64/MSYS2, MSVC, Cygwin, and
   Mac OS X platforms with fixes for all obvious issues discovered with
   these tests (or if the fix is not obvious or is complex, dropped
   components of PLplot for the platform in question).

   The status of this project is as follows:

   The comprehensive tests on Linux have been recently finished
   successfully by me (actually for a case where the prefixes for the
   source, build, and install trees all contained a space, the platform
   was fully installed so all relevant components of PLplot were
   tested, and the tests were done for both noninteractive and
   interactive components of PLplot).  In sum, we are in good shape
   on Linux.

   Arjen has completed a successful comprehensive test of all relevant
   noninteractive components of Cygwin much earlier in this release
   cycle, and more recently he has completed preliminary successful comprehensive
   tests of limited noninteractive components of PLplot for both the
   MinGW-w64/MSYS2 and MSVC platforms.

   My understanding is Arjen plans to follow up by comprehensive tests
   of the relevant complete noninteractive components of PLplot on
   Cygwin (this will be a repeat of his earlier test to confirm we are
   in great shape on this platform for the latest PLplot),
   MinGW-w64/MSYS2 (fully installed this time), and MSVC (with one
   noninteractive component removed that did not work last time). And
   once he is successful with a simple interactive test of wxwidgets on
   MinGW-w64/MSYS2, he plans to follow up with comprehensive
   interactive tests of just the wxwidgets component of PLplot on both
   MinGW-w64/MSYS2 and MSVC (but not Cygwin because of that platform's
   insistence on using X-based graphics which is a great decision on
   POSIX platforms but a lousy one on any Windows-based platform like
   Cygwin because X is so slow on Windows).

   If some volunteer steps forward to do a comprehensive test of
   the latest PLplot on Mac OS X, that would be nice, but I don't view
   that as release critical.

* Fix const correctness.

   The status of that project is it is still in the planning stages,
   but I have decided my old plan (explained in the release notes for
   5.12.0) to change most PLplot generic pointers to have the const
   attribute is a bad way to create const correctness because that
   imposes a long-term burden on users of these argument types to never
   pass back information using the generic pointers in their callbacks.
   So I am going to back away from that plan and go back to what we had
   in 5.11.1 which was all our generic pointers in our API have the
   type PLPointer which is typedefed to void *, and the new generic
   pointers PL_NC_GENERIC_POINTER and PL_GENERIC_POINTER (both of which
   were typedefed to void * in 5.12.0, but there _were_ big plans to
   change PL_GENERIC_POINTER to const void * and use that type for the
   majority of our generic pointer API) will be dropped.

   A "would be nice" would be also to eliminate all const correctness
   concerns (as revealed by the appropriate gcc options)
   by doing the appropriate deep copies of const types to
   non-const types when necessary.

------- Projects that are less release critical

* Fix well-known fill issues.

   The status is there are a number of well-known bugs/misdesigns in
   the current fill code which I want to fix, but with a lot of caution
   because fills are an ubiquitous part of plotting, and the current
   fill code is "good enough" for most purposes, i.e., it performs
   flawlessly for the current standard examples.  However, those fixes
   should not take me that long to complete when I resurrect that topic
   branch (as I promised to do for this release cycle).  If those
   planned fixes don't generate any fill issues for our current
   standard examples, then I plan to push it to our master branch. Of
   course, it would be nice if that pushed branch also fixed the fill
   problem demonstrated by Phil's special test code, but if not, that
   branch merge is still worthwhile because it should clarify the fill
   code and thus make any necessary further fill fixes much easier to
   do.

* Sort out the long-standing OCaml PostScript differences for examples
   8, 16, 19, and 33.

   The status of this project is I have already dealt with
   the example 8 differences, and I am in the middle of
   dealing with the example 19 differences.  I don't know
   whether I will be able to get to the example 16 and 23
   differences before the release or not.

Note all the above topics have uncertain timing so this release will
be ready "when it is ready".  However, I view the first 3 topics
(debug Windows variant of the 3 semaphores approach, comprehensive
testing, and fix const correctness) as much more release critical than the
last 2 topics so if the first three are completed before either one or
both of the last two topics, then in the interest of getting our work
for this release cycle accessible to users in a timely manner, I would
be inclined to drop the unfinished topics and proceed immediately to a
release.  So with some luck and depending on how much time Arjen has
for PLplot this month, the phrase "near future" might translate into a
July release rather than an August release.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, July 01, 2017 11:08 PM
>
> Hi Arjen:
>
> After reviewing the code, I spotted a fundamental error in the Windows variant of
> the three-semaphores case which is that code used three Windows mutexes rather
> than three named Windows semaphores. When I originally coded that variant, I
> naively assumed that a two-state semaphore was effectively the same as a mutex,
> but the semantics are slightly different, and now that I have discovered named
> Windows semaphores I would prefer to use them to keep the Windows variant of
> the 3-semaphores approach as close as possible to the Posix variant of this
> approach.  Therefore, I have now (commit b779495) addressed this issue by using
> named Windows semaphores in the Windows variant of the three semaphores
> approach, but I cannot even build test this modified Windows variant of the three-
> semaphores approach here. So I need you to do that.

I rebuilt PLplot using this latest commit and it all worked fine :). So the three-semaphores approach you have now implemented was the right way. I will try and see whether I can get the same result with the MSVC compiler.

>
> To be specific about what test I want you to run, please freshly configure PLplot
> with the -DPLPLOT_WX_DEBUG_OUTPUT=ON option (which adds lots of useful
> information if there are any remaining errors with the three-semaphores approach).
>
Unless you think this is necessary, given the completely positive results, I will concentrate on MSVC.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-30 00:24-0700 Alan W. Irwin wrote:

> On 2017-06-29 19:52-0000 Arjen Markus wrote:
>> *** PLPLOT WARNING ***
>> wxPLViewer failed to signal it has found the shared memory [on the MinGW-w64/MSYS2 platform].

> I assume this issue is due to some programming error in my Windows
> variant of the 3-semaphores IPC approach.

Hi Arjen:

After reviewing the code, I spotted a fundamental error in the Windows
variant of the three-semaphores case which is that code used three
Windows mutexes rather than three named Windows semaphores. When I
originally coded that variant, I naively assumed that a two-state
semaphore was effectively the same as a mutex, but the semantics are
slightly different, and now that I have discovered named Windows
semaphores I would prefer to use them to keep the Windows variant of
the 3-semaphores approach as close as possible to the Posix variant of
this approach.  Therefore, I have now (commit b779495) addressed this
issue by using named Windows semaphores in the Windows variant of the
three semaphores approach, but I cannot even build test this modified
Windows variant of the three-semaphores approach here. So I need you
to do that.

To be specific about what test I want you to run, please freshly configure
PLplot with the -DPLPLOT_WX_DEBUG_OUTPUT=ON option (which adds lots of
useful information if there are any remaining errors with the
three-semaphores approach).

As per usual, the cmake stdout and stderr output should be captured with

cmake <cmake options> <directory corresponding to top of source tree> >& cmake.out

Then do the following:

# Build prerequisites
make VERBOSE=1 wxwidgets >& wxwidgets.out
make VERBOSE=1 wxPLViewer >& wxPLViewer.out
make VERBOSE=1 x00c >& x00c.out

# Run test

examples/c/x00c -dev wxwidgets >& test.out

Then, please send me those 5 *.out files if there are any issues
captured by any of them.  But I assume you won't have to do that
because there will be no issues.  :-)

By the way, Happy Canada Day everybody!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-29 19:52-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, June 28, 2017 9:44 PM
>>
>>
>> I am now looking forward to your -fabi-version=8 wxwidgets results for
>> MinGW-w64/MSYS2 as well as your wxwidgets results for MSVC.
>>

> I added the option -DCMAKE_CXX_FLAGS="-fabi-version=8" to the CMake
invocation and that did the trick insofar that the runtime error
message about the ABI mismatch has disappeared.

Hi Arjen:

I was pretty sure, the -fabi-version=8 workaround would solve the ABI
mismatch, but it is great to get that confirmed.  However, apparently
from comments made on the MSYS2 list it is just a temporary workaround
for ABI problems the MinGW-w64/MSYS2 platform currently has
(apparently from ABI consistency errors that sometimes occur for their
non-automated official build system).  But, of course, once that
MinGW-w64/MSYS2 official build issue is solved, then your subsequent
system update will get another error box from wxwidgets which will
have to be solved by likely removing the above workaround. However, if
removal does not work, then (as now) you can read the ABI number of
the libraries from the error message (which was 1008 in your present
error message), subtract 1000 from it and adopt that value for n when
setting -fabi-version=n.


> but still no luck otherwise:
> < 8> wxwidgets  wxWidgets Driver
> < 9> svg        Scalable Vector Graphics (SVG 1.1)
> <10> pdf        Portable Document Format PDF
> <11> pdfcairo   Cairo PDF Driver
> <12> pscairo    Cairo PS Driver
> <13> epscairo   Cairo EPS Driver
> <14> svgcairo   Cairo SVG Driver
> <15> pngcairo   Cairo PNG Driver
> <16> memcairo   Cairo Memory Driver
> <17> extcairo   Cairo External Context Driver
> <18> wincairo   Cairo Microscoft Windows Driver
>
> Enter device number or keyword:
> *** PLPLOT WARNING ***
> wxPLViewer failed to signal it has found the shared memory.
>
> markus@L01259 MINGW64 /d/plplot-svn/build-mingw-alt/examples/c
> $ ../../utils/wxPLViewer

> wxPlViewerApp::OnInit: error when creating wxPlFrame instance.  The
message was Error initializing the shared memory and/or mutex needed
for the application. The application will close


>
> markus@L01259 MINGW64 /d/plplot-svn/build-mingw-alt/examples/c
> $
>

> Running an example with the wxWidgets driver gave the message about
wxPLViewer failing and running the wxPLViewer independently gave the
error about the shared memory/mutex.

I assume this issue is due to some programming error in my Windows
variant of the 3-semaphores IPC approach, but it should be a small
error because the Posix variant of that code works fine for the Linux
case, and the code differences between these two variants are small.
In fact, those Windows differences are simply in low-level syntax
about how the three semaphores are created, initialized and used, for
the Windows case, and I copied that syntax from the old IPC code.
Anyhow, whatever the logic error it is very likely appearing somewhere
in the code where #ifdef win32 logic blocks appear inside #ifdef
PL_WXWIDGETS_IPC3 logic blocks.  If I don't spot anything inside those
limited code areas (and assuming you don't beat me to finding the
error yourself) I plan to commit some extra debug output near where
your error messages above state the error is occurring in the code,
and get back to you (likely during this weekend) asking for a test
that emits those debug messages.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 28, 2017 9:44 PM
>
>
> I am now looking forward to your -fabi-version=8 wxwidgets results for
> MinGW-w64/MSYS2 as well as your wxwidgets results for MSVC.
>
I added the option -DCMAKE_CXX_FLAGS="-fabi-version=8" to the CMake invocation and that did the trick insofar that the runtime error message about the ABI mismatch has disappeared, but still no luck otherwise:
< 8> wxwidgets  wxWidgets Driver
< 9> svg        Scalable Vector Graphics (SVG 1.1)
<10> pdf        Portable Document Format PDF
<11> pdfcairo   Cairo PDF Driver
<12> pscairo    Cairo PS Driver
<13> epscairo   Cairo EPS Driver
<14> svgcairo   Cairo SVG Driver
<15> pngcairo   Cairo PNG Driver
<16> memcairo   Cairo Memory Driver
<17> extcairo   Cairo External Context Driver
<18> wincairo   Cairo Microscoft Windows Driver

Enter device number or keyword:
*** PLPLOT WARNING ***
wxPLViewer failed to signal it has found the shared memory.

markus@L01259 MINGW64 /d/plplot-svn/build-mingw-alt/examples/c
$ ../../utils/wxPLViewer
wxPlViewerApp::OnInit: error when creating wxPlFrame instance.  The message was Error initializing the shared memory and/or mutex needed for the application. The application will close

markus@L01259 MINGW64 /d/plplot-svn/build-mingw-alt/examples/c
$

Running an example with the wxWidgets driver gave the message about wxPLViewer failing and running the wxPLViewer independently gave the error about the shared memory/mutex.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 28, 2017 9:44 PM
>
> Yes, you are certainly correct to be concerned about that issue; I assume the same
> ABI incompatibility issues occur on the MSVC side of things as occur on the g++
> side of things.  But the MSVC ABI changes might not occur so often as they do for
> g++ so your wxwidgets distribution might still be ABI compatible with the version of
> the MSVC compiler you are using. So it is "try it and see" with MSVC.
>
I originally only found the source distribution for wxWidgets, but it seems that a binary distribution is available on www.wxwidgets.org<http://www.wxwidgets.org> for a range of MSVC compiler versions (2008-2017). I plan to use the 3.0.3 release from that site.

> Actually I am quite impressed with wxwidgets popping an error box concerning ABI
> incompatibility (at least for the g++ case but hopefully for the MSVC case as well).
> Most software projects typically have lower standards then that and simply make no
> effort to detect ABI incompatibility issues so the user has to discover for
> themselves such problems via run-time issues such as segfaults.
>
> I am now looking forward to your -fabi-version=8 wxwidgets results for
> MinGW-w64/MSYS2 as well as your wxwidgets results for MSVC.
>
Hopefully I will know more tonight.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-28 08:01-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, June 28, 2017 9:48 AM
>
>> Of course, now that the build issues are fixed, and you found this one run time error,
>> the pessimistic view is there might be other run-time issues to be dealt with after
>> this one is dealt with, but I am more optimistic than that.  Thus, I am hoping this is
>> the last wxwidgets error you will have to deal with that is specific to MinGW-
>> w64/MSYS2, and I am hoping that -fabi-version=8 will fix this issue on that platform.
>> So I was glad to hear you are going to give this experiment a try.
>>

> There may be a way out for the MSVC constellation as well - I just
found that in my distribution of wxWidgets there _are_ prebuilt
libraries contained.

For the record, what distribution of wxwidgets are you planning to use
with MSVC? Once you state that, it is possible that Phil or Pedro have
attempted to use that same distribution of wxwidgets and can tell us
of their good/bad experiences with it.

> I just do not know if these are compatible with my [MSVC] compiler.

Yes, you are certainly correct to be concerned about that issue; I
assume the same ABI incompatibility issues occur on the MSVC side of
things as occur on the g++ side of things.  But the MSVC ABI changes
might not occur so often as they do for g++ so your wxwidgets
distribution might still be ABI compatible with the version of the
MSVC compiler you are using. So it is "try it and see" with MSVC.

Actually I am quite impressed with wxwidgets popping an error box
concerning ABI incompatibility (at least for the g++ case but
hopefully for the MSVC case as well).  Most software projects
typically have lower standards then that and simply make no effort to
detect ABI incompatibility issues so the user has to discover for
themselves such problems via run-time issues such as segfaults.

I am now looking forward to your -fabi-version=8 wxwidgets results for
MinGW-w64/MSYS2 as well as your wxwidgets results for MSVC.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 28, 2017 9:48 AM
>
>
> In the heat of the moment I forgot to say something that I will say now.  It was a
> huge milestone to get the PLplot components of wxwidgets building on MinGW-
> w64/MSYS2 considering where we started from.  So I think congratulations are in
> order for both of us.  :-)
>

True, true, but stumbling just before the finish has a disappointing effect :).

> Of course, now that the build issues are fixed, and you found this one run time error,
> the pessimistic view is there might be other run-time issues to be dealt with after
> this one is dealt with, but I am more optimistic than that.  Thus, I am hoping this is
> the last wxwidgets error you will have to deal with that is specific to MinGW-
> w64/MSYS2, and I am hoping that -fabi-version=8 will fix this issue on that platform.
> So I was glad to hear you are going to give this experiment a try.
>
There may be a way out for the MSVC constellation as well - I just found that in my distribution of wxWidgets there _are_ prebuilt libraries contained. I just do not know if these are compatible with my compiler. The directory structure is vast so they escaped my first survey.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-28 07:00-0000 Arjen Markus wrote:

>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, June 28, 2017 3:01 AM
>>
[...] 
>> When faced with a fatal error like that, google is your friend.
>
>
> It was getting late, my laptop's battery was nearing its limit and I thought perhaps some conflicting versions of the wxWidgets were being accessed. ldd, though, did not show anything untowards. So then I focussed on the MSVC/wxWidgets constellation ...
>
> First disappointment: a quick search did not bring up any ready-made distributions but instead the advice to build it yourself from source. So I tried this. And that was the second disappointment. There is a so-called solution (MicroSoft's answer to makefiles) in the source distribution I retrieved, so I could load it into Visual Studio (whereas the wxWidgets Wiki described only the now virtually extinct Developer Studio, which uses a different approach). Building the solution (that is: the set of libraries) quickly brought up 92 compile errors of the type:
>
> ..\..\src\stc\scintilla\lexers\LexA68k.cxx(131): error C2664: 'StyleContext::StyleContext(unsigned int,unsigned int,int,LexAccessor &,char)' : cannot convert parameter 4 from 'Accessor' to 'LexAccessor &'
>
> Not the sort of things I enjoy debugging.

Well, an epa_build of wxwidgets obviously works for me so that is always
an approach you could take if nothing else works.  But I am pretty sure
you won't have to be concerned with a wxwidgets (epa_)build
because the trick below with -fabi-version=8 should fix the
ABI incompatibility issue.


>> I am going to follow up with a short version of this to the MSYS2 mailing list asking
>> if setting -fabi-version=8 is the right response to the above error message, but
>> please go ahead and try that experiment right away, and don't wait for their
>> comments (if any).
>>
> Seen that. I will write a short reply - the annoying thing is that this is only detected at run-time, not at build-time.

In the heat of the moment I forgot to say something that I will say
now.  It was a huge milestone to get the PLplot components of
wxwidgets building on MinGW-w64/MSYS2 considering where we started
from.  So I think congratulations are in order for both of us.  :-)

Of course, now that the build issues are fixed, and you found this one
run time error, the pessimistic view is there might be other run-time
issues to be dealt with after this one is dealt with, but I am more
optimistic than that.  Thus, I am hoping this is the last wxwidgets
error you will have to deal with that is specific to MinGW-w64/MSYS2,
and I am hoping that -fabi-version=8 will fix this issue on that
platform.  So I was glad to hear you are going to give this experiment
a try.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 28, 2017 3:01 AM
>
> Hi Arjen:
>
>
> When faced with a fatal error like that, google is your friend.


It was getting late, my laptop's battery was nearing its limit and I thought perhaps some conflicting versions of the wxWidgets were being accessed. ldd, though, did not show anything untowards. So then I focussed on the MSVC/wxWidgets constellation ...

First disappointment: a quick search did not bring up any ready-made distributions but instead the advice to build it yourself from source. So I tried this. And that was the second disappointment. There is a so-called solution (MicroSoft's answer to makefiles) in the source distribution I retrieved, so I could load it into Visual Studio (whereas the wxWidgets Wiki described only the now virtually extinct Developer Studio, which uses a different approach). Building the solution (that is: the set of libraries) quickly brought up 92 compile errors of the type:

..\..\src\stc\scintilla\lexers\LexA68k.cxx(131): error C2664: 'StyleContext::StyleContext(unsigned int,unsigned int,int,LexAccessor &,char)' : cannot convert parameter 4 from 'Accessor' to 'LexAccessor &'

Not the sort of things I enjoy debugging.

> Indeed, when I made a google search for the terms <"c++" abi 1008
> 1010>, I quickly found a discussion about how strict wxwidgets should
> be concerning its default rule that C++ ABI version numbers should be exactly
> identical (as you discovered above). Furthermore,
> <https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html> states the ABI
> versioning scheme for a relatively old version of gcc is
>
> In sum from this google research based on the above error message, I am pretty
> sure what happened is that the MinGW-w64/MSYS2 wxwidgets libraries were built
> with some g++ version from 4.9.z through g++ 5.1.z, and you are building the
> wxwidgets components of PLplot using
> g++ version 6.x.y, where x is 1 or greater.  Furthermore, from
> the above Dialect options site, I believe all you have to do to avoid this issue is
> specify -fabi-version=8 as a g++ option (e.g., by adding that option to the
> CXXFLAGS environment variable).
>
That is certainly worth a try

> I am going to follow up with a short version of this to the MSYS2 mailing list asking
> if setting -fabi-version=8 is the right response to the above error message, but
> please go ahead and try that experiment right away, and don't wait for their
> comments (if any).
>
Seen that. I will write a short reply - the annoying thing is that this is only detected at run-time, not at build-time.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-27 18:22-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> I could say "I have good news and bad news". First of all, with this latest version I can indeed build the wxWidgets driver without complaints, using the 64-bits version of MinGW-w64/MSYS2, but when I run an example I get:
>
>
>
> [cid:image001.png@01D2EF82.D7F76F70]
>
>
>

> I guess this means that I should be using _exactly_ the same
compiler to build PLplot as was used to build the wxWidgets libraries.
Quite possibly the easiest way is to build these libraries from
source, so that there can be no mismatch - sigh.

Hi Arjen:

I think your proposed solution would work, but I propose a much
more convenient solution below concerning this ABI incompatibility issue
that is based on some google research I did.

For the record, here is the message in that fatal error message box
image (which I will cut and paste to the MSYS2 mailing list when I
follow up there).

Mismatch between the program and library build versions detected. The
library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx
containers,compatible with 2.8), and your program used 3.0
(wchar_t,compiler with C++ ABI 1010,wx containers,compatible with
2.8).

When faced with a fatal error like that, google is your friend. 
Indeed, when I made a google search for the terms <"c++" abi 1008
1010>, I quickly found a discussion about how strict wxwidgets should
be concerning its default rule that C++ ABI version numbers should be
exactly identical (as you discovered above). Furthermore,
<https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html> states the
ABI versioning scheme for a relatively old version of gcc is

GCC 3.4, GCC 4.x: 1000 + n (when n>1)

If that scheme contines for the g++ versions available for
MinGW-w64/MSYS2, it appears from the above notice, that
the MinGW-w64/MSYS2 developers
built the wxwidgets libraries implicitly with -fabi-version=8, and you
built the wxwidgets components of PLplot with -fabi-version=10.
Furthermore, from
<https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html>
ABI versions 1008, 1009, 1010, and 1011 first appeared in g++ versions 4.9,
5.2, 6.1, and 7.

Finally, I found
<https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-wxwidgets/wxWidgets-3.0.2-relax-abi-compatibility-gcc.patch>
which relaxes the default strict ABI compatibility rule for wxwidgets
BUT only for the ABI range 1002-1008.  So this patch does mean the above
error will occur for your case (1008 and 1010).

In sum from this google research based on the above error message, I
am pretty sure what happened is that the MinGW-w64/MSYS2 wxwidgets
libraries were built with some g++ version from 4.9.z through g++
5.1.z, and you are building the wxwidgets components of PLplot using
g++ version 6.x.y, where x is 1 or greater.  Furthermore, from
the above Dialect options site, I believe all you have to
do to avoid this issue is specify -fabi-version=8 as a g++
option (e.g., by adding that option to the CXXFLAGS environment
variable).

I am going to follow up with a short version of this to the MSYS2
mailing list asking if setting -fabi-version=8 is the right response
to the above error message, but please go ahead and try that
experiment right away, and don't wait for their comments (if any).

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



I could say "I have good news and bad news". First of all, with this latest version I can indeed build the wxWidgets driver without complaints, using the 64-bits version of MinGW-w64/MSYS2, but when I run an example I get:



[cid:image001.png@01D2EF82.D7F76F70]



I guess this means that I should be using _exactly_ the same compiler to build PLplot as was used to build the wxWidgets libraries. Quite possibly the easiest way is to build these libraries from source, so that there can be no mismatch - sigh.



Hm, if that is true, why was I able to create a small example? That ran and did not have this issue. Any thoughts?



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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-27 07:40-0000 Arjen Markus wrote:

> An inspection of the code did not bring up a glaring mistake [in the
declaration of ran_s], so I
am puzzled as well. At the very least at the moment. The only thing I
can imagine is that the stdlib.h header file is not actually included.

Hi Arjen:

I also did a google search for ran_s and Wine, and that was
implemented long ago in the msvcrt library (which I assume is
automatically propagated on Windows platforms to what g++ feels is
stdlib).  So I am puzzled indeed, but we will know more once we get
your results for your more usual Windows platforms and also for a much more
modern g++ for your MinGW-w64/MSYS2 platform than I am running on
my ancient MinGW/MSYS platform.

>
>> In sum, please run a MinGW-w64/MSYS2 (either 32-bit or 64-bit) test and an
>> MSVC test for this latest code base to insure my present fix works for the "cannot
>> convert" LPCTSTR to LPCWSTR issue works on those platforms.  And if for either
>> one you run into a problem with the above declaration of rand_s, I hope you know
>> how to fix it (since I don't).
>>
> Okay, that is clear enough. I will try this.

Thanks!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, June 27, 2017 9:12 AM
>
> However, (see commit message for details) I ran into one other build issue
> concerning the declaration of rand_s which is implemented in
> drivers/wxwidgets_dev.cpp with the following two lines:
>
> #define _CRT_RAND_S
> #include <stdlib.h>
>
> This declaration method is exactly what is suggested by
> <https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx>, and appeared to work
> fine for Phil during his pre-release testing of PLplot-5.12.0 on the MSVC platform,
> and I suspect (but need confirmation from you) it also won't be a problem on that
> platform for this version of the code.  But at least my version 4.7.2 of g++ on
> MinGW/MSYS is complaining about that declaration so my guess (which needs
> confirmation from you) is you will run into the same issue for modern
> g++ on MinGW-w64/MSYS2 (either 32-bit or 64-bit).  In which case, I
> hope you have the C++ expertise (which I don't have) to figure out what change you
> have to make in the rand_s declaration to convince g++ to compile that code.
>

An inspection of the code did not bring up a glaring mistake, so I am puzzled as well. At the very least at the moment. The only thing I can imagine is that the stdlib.h header file is not actually included.

> In sum, please run a MinGW-w64/MSYS2 (either 32-bit or 64-bit) test and an
> MSVC test for this latest code base to insure my present fix works for the "cannot
> convert" LPCTSTR to LPCWSTR issue works on those platforms.  And if for either
> one you run into a problem with the above declaration of rand_s, I hope you know
> how to fix it (since I don't).
>
Okay, that is clear enough. I will try this.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Arjen:

Commit 76f6a78 includes a simple fix for the "cannot convert" LPCTSTR
to LPCWSTR build issues you discovered that has been bugging us for qute
some time now and which I was recently able to verify on my
Wine/MinGW/MSYS platform.  So I think this fix is a big
step forward.

However, (see commit message for details) I ran into one other build
issue concerning the declaration of rand_s which is implemented in
drivers/wxwidgets_dev.cpp with the following two lines:

#define _CRT_RAND_S
#include <stdlib.h>

This declaration method is exactly what is suggested by
<https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx>, and appeared
to work fine for Phil during his pre-release testing of PLplot-5.12.0
on the MSVC platform, and I suspect (but need confirmation from you)
it also won't be a problem on that platform for this version of the
code.  But at least my version 4.7.2 of g++ on MinGW/MSYS is
complaining about that declaration so my guess (which needs
confirmation from you) is you will run into the same issue for modern
g++ on MinGW-w64/MSYS2 (either 32-bit or 64-bit).  In which case, I
hope you have the C++ expertise (which I don't have) to figure out
what change you have to make in the rand_s declaration to convince g++
to compile that code.

In sum, please run a MinGW-w64/MSYS2 (either 32-bit or 64-bit) test
and an MSVC test for this latest code base to insure my present fix
works for the "cannot convert" LPCTSTR to LPCWSTR issue works on those
platforms.  And if for either one you run into a problem with the above
declaration of rand_s, I hope you know how to fix it (since I don't).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, June 27, 2017 1:06 AM
> To: Arjen Markus; PLplot development list; Phil Rosenberg; Pedro Vicente
> Subject: RE: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2
>
> To Arjen, Phil, and Pedro:
>
>
> @Phil and Pedro: what set of wxwidgets libraries do you use to test PLplot
> wxwidgets components on the MSVC platform?  That information would be useful
> to Arjen (see the last part of the rest of this post).
>
> @Arjen: the rest of this is largely for you.
>
> It turns out I can now finally replicate the wxwidgets build bug you discovered! I got
> this result on my Windows platform consisting of Wine staging 2.10 + an ancient
> (but thankfully still working) snapshot of MinGW/MSYS (4.7.2) + epa_build (on
> Wine-stagine/MinGW/MSYS) of wxwidgets-3.0.2.  Note that this is a 32-bit platform
> because the wine command (as opposed to the wine64
> command) implements 32-bit Windows, and, in any case, MinGW/MSYS was
> always 32-bit as well (unlike MinGW-w64/MSYS2 which implements both 32-bit and
> 64-bit versions).  So all the web reports saying this issue was limited to 64-bit
> platforms is obviously incorrect.

Well, not entirely - see below.

>
> For some reason, the wxwidgets find on this platform plus some of our further logic
> in cmake/modules/wxwidgets.cmake to test the wxwidgets version failed because
> wxWidgets_INCLUDE_DIRS was in /<drive letter>/ form.  To get around that
> limitation I have locally implemented some logic to append a variant of
> wxWidgets_INCLUDE_DIRS to wxWidgets_INCLUDE_DIRS that has been
> converted from that form to the corresponding <drive letter>:/ form.  I have no idea
> why this change is necessary but it does work, and I don't think it will interfere with
> anything else so I plan to finalize and commit this change (even though you don't
> seem to have encountered this issue on MinGW-w64/MSYS2).
>
> The initial error message (similar to what you reported) is
>
> z:/home/wine/wine_staging/build_results/install-
> 2.10_jessie_wine_staging/include/wx-3.0/wx/msw/winundef.h:38:20:
> error: cannot convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const
> wchar_t*}' for argument '2' to 'HWND__* CreateDialogParamW(HINSTANCE,
> LPCWSTR, HWND, DLGPROC, LPARAM)'
>
...

>
> Since I can now replicate the issue you found, and I still view this issue as release
> critical I intend to work on it until I solve it.
> Of course, you are welcome to continue to work on this issue (e.g., by trying a 32-
> bit MinGW-w64/MSYS2 build [which from the above 32-bit evidence will probably
> generate the equivalent build error, but you never know], beating me to a solution,
> or adding some essential insight that helps me find a solution). However, it would
> likely be more efficient (in terms of reaching the goal of getting the next release out
> in a timely manner) if you switched to testing wxwidgets for the MSVC case.
> According to Phil's tests, wxwidgets did work fine for the MSVC platform just before
> we released PLplot-5.12.0 so it is definitely release critical if it turns out wxwidgets
> no longer works on that platform!
>
Last night I installed the 32-bits version of MinGW-w64/SYS2 and that built wxWidgets without any trouble. So the reports about "64 bits MinGW" being at fault are not entirely incorrect.

The trouble came from a different source: the haru library needed for the PDF device. This turns out to be built using the "stdcall" convention (one of the reasons I greatly prefer to work with 64 bits on Windows!) and thus I got error messages like the ones below:

[ 19%] Linking C shared module ../dll/pdf.dll

cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/cmake.exe -E remove -f CMakeFiles/pdf.dir/objects.a

cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/ar.exe cr CMakeFiles/pdf.dir/objects.a "CMakeFiles/pdf.dir/pdf.c.obj"

cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/gcc.exe     -shared -o ../dll/pdf.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/pdf.dir/objects.a -Wl,--no-whole-archive ../dll/libplplot.dll.a /D/mingw32/mingw32/lib/libhpdf.dll.a /D/mingw32/mingw32/lib/libshp.dll.a /D/mingw32/mingw32/lib/libfreetype.dll.a ../dll/libcsirocsa.dll.a ../dll/libcsironn.dll.a /D/mingw32/mingw32/lib/libqhull.dll.a ../dll/libqsastime.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x293): undefined reference to `_imp__HPDF_New'

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x2d1): undefined reference to `_imp__HPDF_SetCompressionMode'

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x423): undefined reference to `_imp__HPDF_AddPage'

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x45a): undefined reference to `_imp__HPDF_Page_SetSize'

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x47e): undefined reference to `_imp__HPDF_Page_SetSize'

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x48e): undefined reference to `_imp__HPDF_Page_GetWidth'

As I know the origin of these errors, it might be easy (or not) to fix this.

> If you are willing to move to testing our wxwidgets components for MSVC, then one
> issue is how do you gain access to the wxwidgets libraries for the MSVC platform?
> The web advice concerning that issue seems to be pretty uniform which
> (presumably because of ABI consistency issues) is to build your own wxwidgets
> libraries using the identical compiler that you use to build your wxwidgets application
> (or wxwidgets-related PLplot applications and libraries in our case).
> My initial google search found
> <https://stackoverflow.com/questions/37995066/how-to-set-up-wxwidgets-3-1-0-
> with-visual-studio-2015>
> which contains a summary of what is needed in the MSVC case, but your own
> google searches may find a better reference.  And if either or both Phil or Pedro
> respond to the question above, that should help as well!
>
Yes, I will have a look at the MSVC variant and leave this issue to you. Not sure how much time I can spend though, we'll see.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

To Arjen, Phil, and Pedro:


@Phil and Pedro: what set of wxwidgets libraries do you use to test
PLplot wxwidgets components on the MSVC platform?  That information
would be useful to Arjen (see the last part of the rest of this
post).

@Arjen: the rest of this is largely for you.

It turns out I can now finally replicate
the wxwidgets build bug you discovered! I got this result on my
Windows platform consisting of Wine staging 2.10 + an ancient (but
thankfully still working) snapshot of MinGW/MSYS (4.7.2) + epa_build
(on Wine-stagine/MinGW/MSYS) of wxwidgets-3.0.2.  Note that this is a
32-bit platform because the wine command (as opposed to the wine64
command) implements 32-bit Windows, and, in any case, MinGW/MSYS was
always 32-bit as well (unlike MinGW-w64/MSYS2 which implements both
32-bit and 64-bit versions).  So all the web reports saying this issue
was limited to 64-bit platforms is obviously incorrect.

For some reason, the wxwidgets find on this platform plus some of our
further logic in cmake/modules/wxwidgets.cmake to test the wxwidgets
version failed because wxWidgets_INCLUDE_DIRS was in /<drive letter>/
form.  To get around that limitation I have locally implemented some
logic to append a variant of wxWidgets_INCLUDE_DIRS to
wxWidgets_INCLUDE_DIRS that has been converted from that form to the
corresponding <drive letter>:/ form.  I have no idea why this change
is necessary but it does work, and I don't think it will interfere
with anything else so I plan to finalize and commit this change (even
though you don't seem to have encountered this issue on
MinGW-w64/MSYS2).

The initial error message (similar to what you reported) is

z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/include/wx-3.0/wx/msw/winundef.h:38:20:
error: cannot convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' for argument '2' to 'HWND__*
CreateDialogParamW(HINSTANCE, LPCWSTR, HWND, DLGPROC, LPARAM)'

My test that generated that error was the following command (on one
line rather than e-mail wrapped as here)

${EPA_BUILD_SOURCE_PATH}/../../scripts/comprehensive_test.sh --prefix
comprehensive_test_disposable --generator_string "MSYS Makefiles"
--cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON
-DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON" --build_command make
--ctest_command ctest --do_nondynamic no --do_static no
--do_test_noninteractive no --do_ctest no --do_test_install_tree no
--do_test_traditional_install_tree no

Those options mean the results are limited to the wxwidgets components
of PLplot, and to speed the test (for now) just interactive testing is
done for just the shared libraries case and just the build tree.  So
this is roughly equivalent to some hand-tests you have been making
with the advantage of a generated tarball report (attached) that
includes essentially all details in standard form to help debug this
issue further.

Since I can now replicate the issue you found, and I still view this
issue as release critical I intend to work on it until I solve it. 
Of course, you are welcome to continue to work on this issue (e.g., by
trying a 32-bit MinGW-w64/MSYS2 build [which from the above 32-bit
evidence will probably generate the equivalent build error, but you
never know], beating me to a solution, or adding some essential
insight that helps me find a solution). However, it would likely be
more efficient (in terms of reaching the goal of getting the next
release out in a timely manner) if you switched to testing wxwidgets
for the MSVC case. According to Phil's tests, wxwidgets did work fine
for the MSVC platform just before we released PLplot-5.12.0 so it is
definitely release critical if it turns out wxwidgets no longer works
on that platform!

If you are willing to move to testing our wxwidgets components for
MSVC, then one issue is how do you gain access to the wxwidgets
libraries for the MSVC platform? The web advice concerning that issue
seems to be pretty uniform which (presumably because of ABI
consistency issues) is to build your own wxwidgets libraries using the
identical compiler that you use to build your wxwidgets application
(or wxwidgets-related PLplot applications and libraries in our case).
My initial google search found
<https://stackoverflow.com/questions/37995066/how-to-set-up-wxwidgets-3-1-0-with-visual-studio-2015>
which contains a summary of what is needed in the MSVC case, but your
own google searches may find a better reference.  And if either or
both Phil or Pedro respond to the question above, that should help as
well!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-23 11:12-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Friday, June 23, 2017 1:04 PM
>>
>> Hi Arjen:
>>
>> Thanks very much for that quick turnaround.
>>
> You're welcome :)
>
>>> I get compile errors as can be seen in the attached tarball (output
>> from CMake and make, as well as the config header file). We need to sort out these
>> things before a comprehensive build is going to stand any chance.
>>
>> From what I can tell from your current extremely limited make.out (please generate
>> that next time with VERBOSE=1), it looks like these build issues have nothing to do
>> with PLplot code and instead are wxwidgets header incompatibilities _for the
>> compile flags that are being generated by your current  Unix wxwidgets find
>> method_.
>>
>> Therefore, I am pretty sure the current build issue is caused by your build using
>> Unix wxwidgets compile and link flags when it should be using Windows wxwidgets
>> compile and link flags for the MinGW-w64/MSYS2 platform. So to get access to the
>> latter flags, I suggest you use the _Windows_ wxwidgets find method (which I
>> understand you automatically obtain if you use the "MSYS Makefiles" generator.)
>>
>
> I do not think so, the condition definitely says "AND NOT MSYS" - so that would use the Unix method.

You are right.  So without your one-line change to
FindwxWidgets.cmake, the "Unix Makefiles" generator or "MinGW
Makefiles" generator will yield

set(wxWidgets_FIND_STYLE "win32")

while (confusing) the "MSYS Makefiles" generator will yield

set(wxWidgets_FIND_STYLE "unix")

>
>> If I have understood correctly what you said before, the Windows wxwidgets find
>> method currently does not work for the MinGW-w64/MSYS2 platform. Nevertheless,
>> since our wxwidgets code with old IPC method did build correctly on MSVC before
>> with this find method, I assume whatever correction you have to make to
>> cmake/modules/findwxWidgets.cmake to get the Windows find method to work
>> correctly on the MinGW-w64/MSYS2 platform should be quite small.
>> And as per usual, the cmake options --debug-output --trace are extremely useful for
>> debugging find modules, but if those are not sufficient to discover the problem, you
>> can always locally insert
>> message(...) commands in cmake/modules/findwxWidgets.cmake.
>>
>

> Ah, but the issue is that under MinGW-w64/MSYS2 things are installed
in different directories and possibly a different structure than under
Windows with MSVC. MinGW-w64/MSYS2 is a bit of a hybrid system, though
leaning towards the Unix way.

I agree on the hybrid nature of that platform and very likely part of
that is the wxwidgets libraries are built on MinGW-w64/MSYS2 the
"Windows" way since X is (thankfully since it is so slow on Windows)
not available on that platform.

Anyhow, I would advise dumping out compile (and link) flag results for both the

set(wxWidgets_FIND_STYLE "win32")

and

set(wxWidgets_FIND_STYLE "unix")

cases to see what the differences are (which I think were originally
designed for the "MinGW Makefiles" and "MSYS Makefiles" cases for the
old MinGW/MSYS platform).

Because of the hybrid nature of MinGW-w64/MSYS2 you might need some
combination of both sets of those compile flags (e.g., -I flags
from "unix" results and the other non-I compile flags from "win32"
results.  Or vice versa).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, June 23, 2017 1:04 PM
>
> Hi Arjen:
>
> Thanks very much for that quick turnaround.
>
You're welcome :)

> > I get compile errors as can be seen in the attached tarball (output
> from CMake and make, as well as the config header file). We need to sort out these
> things before a comprehensive build is going to stand any chance.
>
> From what I can tell from your current extremely limited make.out (please generate
> that next time with VERBOSE=1), it looks like these build issues have nothing to do
> with PLplot code and instead are wxwidgets header incompatibilities _for the
> compile flags that are being generated by your current  Unix wxwidgets find
> method_.
>
> Therefore, I am pretty sure the current build issue is caused by your build using
> Unix wxwidgets compile and link flags when it should be using Windows wxwidgets
> compile and link flags for the MinGW-w64/MSYS2 platform. So to get access to the
> latter flags, I suggest you use the _Windows_ wxwidgets find method (which I
> understand you automatically obtain if you use the "MSYS Makefiles" generator.)
>

I do not think so, the condition definitely says "AND NOT MSYS" - so that would use the Unix method.

> If I have understood correctly what you said before, the Windows wxwidgets find
> method currently does not work for the MinGW-w64/MSYS2 platform. Nevertheless,
> since our wxwidgets code with old IPC method did build correctly on MSVC before
> with this find method, I assume whatever correction you have to make to
> cmake/modules/findwxWidgets.cmake to get the Windows find method to work
> correctly on the MinGW-w64/MSYS2 platform should be quite small.
> And as per usual, the cmake options --debug-output --trace are extremely useful for
> debugging find modules, but if those are not sufficient to discover the problem, you
> can always locally insert
> message(...) commands in cmake/modules/findwxWidgets.cmake.
>

Ah, but the issue is that under MinGW-w64/MSYS2 things are installed in different directories and possibly a different structure than under Windows with MSVC. MinGW-w64/MSYS2 is a bit of a hybrid system, though leaning towards the Unix way.

> Anyhow, good luck with this debugging of the Windows wxwidgets find method on
> MinGW-w64/MSYS2.
>

Thanks, it looks like some more experimenting is required.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

On 2017-06-23 09:40-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Friday, June 23, 2017 11:03 AM
>>
>> As expected since my changes had nothing to do with the find issue that you
>> discovered and solved a couple of days ago.
>>
> Right, I reinstalled this change and got further into the build process.
>
>> Please do start the comprehensive tests I requested when you solved the find
>> problem (at least for the "Unix Makefiles" generator) a couple of days ago.  The
>> reason I have requested those tests is because in my view sorting out any
>> remaining wxwidgets problems for the MinGW-w64/MSYS2 platform is release
>> critical.
>>

Hi Arjen:

Thanks very much for that quick turnaround.

> I get compile errors as can be seen in the attached tarball (output
from CMake and make, as well as the config header file). We need to
sort out these things before a comprehensive build is going to stand
any chance.

>From what I can tell from your current extremely limited make.out
(please generate that next time with VERBOSE=1), it looks like these
build issues have nothing to do with PLplot code and instead are
wxwidgets header incompatibilities _for the compile flags that are
being generated by your current  Unix wxwidgets find method_.

Therefore, I am pretty sure the current build issue is caused by your
build using Unix wxwidgets compile and link flags when it should be
using Windows wxwidgets compile and link flags for the MinGW-w64/MSYS2
platform. So to get access to the latter flags, I suggest you use the
_Windows_ wxwidgets find method (which I understand you automatically
obtain if you use the "MSYS Makefiles" generator.)

If I have understood correctly what you said before, the Windows
wxwidgets find method currently does not work for the MinGW-w64/MSYS2
platform. Nevertheless, since our wxwidgets code with old IPC method
did build correctly on MSVC before with this find method, I assume
whatever correction you have to make to
cmake/modules/findwxWidgets.cmake to get the Windows find method to
work correctly on the MinGW-w64/MSYS2 platform should be quite small.
And as per usual, the cmake options --debug-output --trace are
extremely useful for debugging find modules, but if those are not
sufficient to discover the problem, you can always locally insert
message(...) commands in cmake/modules/findwxWidgets.cmake.

Anyhow, good luck with this debugging of the Windows wxwidgets find
method on MinGW-w64/MSYS2.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, June 23, 2017 11:03 AM
>
> As expected since my changes had nothing to do with the find issue that you
> discovered and solved a couple of days ago.
>
Right, I reinstalled this change and got further into the build process.

> Please do start the comprehensive tests I requested when you solved the find
> problem (at least for the "Unix Makefiles" generator) a couple of days ago.  The
> reason I have requested those tests is because in my view sorting out any
> remaining wxwidgets problems for the MinGW-w64/MSYS2 platform is release
> critical.
>
I get compile errors as can be seen in the attached tarball (output from CMake and make, as well as the config header file). We need to sort out these things before a comprehensive build is going to stand any chance.

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Arjen:

On 2017-06-23 06:55-0000 Arjen Markus wrote:

[...]
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, June 21, 2017 3:02 AM
>>
>> To Arjen and Phil:
>>
>> I have now made these 4 additional wxwidgets-related commits:
>>
>> 2bc0626 IPC for wxwidgets: Reenable the PL_WXWIDGETS_IPC3 option
>> e07d5e5 IPC for wxwidgets: Purge PL_HAVE_UNNAMED_POSIX_SEMAPHORES
>> 2faff23 IPC for wxwidgets: Fix use of WIN32 and PL_WXWIDGETS_IPC3
>> preprocessor macros
>> 8fd52f8 Build System: Implement the
>> PAUSE_CERTAIN_INTERACTIVE_DEVICES option
>>

> I tried the new code, but it fails on properly finding wxWidgets
again.

As expected since my changes had nothing to do with
the find issue that you discovered and solved a couple of days ago.

> as CMake identifies the search method as "Windows". The method is
rather elaborate and fails on finding the libraries. When I tried it
before using the "Unix" method it did work, so I am inclined to use
that instead (reinstating the extra check).  Then the IPC3 option
should kick in properly if I understand the changes correctly. I have
not had time to try it yet though.

Please do start the comprehensive tests I requested when you solved
the find problem (at least for the "Unix Makefiles" generator) a
couple of days ago.  The reason I have requested those tests is
because in my view sorting out any remaining wxwidgets problems for
the MinGW-w64/MSYS2 platform is release critical.

I emphasize wxwidgets comprehensive testing activity should really not
take very much of your time since the interactive comprehensive test
(assuming you adopt the script arguments I recommended to limit the
testing just to wxwidgets) took only 15 minutes here, and during that
time the only "interactive" thing I had to do was to close two
interactive wxwidgets GUIs 9 different times (i.e., for our 3
different kinds of builds for our 3 different major configurations).
And, of course, that time will be much shorter and the number of GUIs
you have to close much fewer, if you run into problems early in the
tests run by the script.  Anyhow, once the wxwidgets-only
comprehensive test has completed, you should send me the report
tarball so I can figure out more source code changes to deal with any
issues that are revealed by that report tarball.

Given how little time per day is required for your part of this testing, and
your earlier off-list statement to me that June would be a convenient
month for you to do testing, would you be willing to run that script
and send me the report tarball once per day (i.e., give me daily
turnaround)?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________