plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] The wxwidgets version you use for MSVC - solved (not quite though)

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

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

[...]
> And then it hit me: I had downloaded the _wrong_ bits
version. From there on it went quite smoothly. After some struggles
with the path I got the build to succeed and got an example to run.

I was very happy to hear that good news from you.

> The only (!) problem left is that on line 378 in wxwidgets_dev.cpp the
variable "offset" is used but was not previously set.
[...]
> A quick check of the source code did not tell me how to solve that, so I will have to leave that to you.

Indeed, I confirm that is an obvious bad case of an uninitialized
variable, and it is up to me to fix it since that code is mine.  But
it is pretty bad code in another respect (quite convoluted) so I
understand it well enough to realize there is a definite uninitialized
variable issue, but it will take me a while to figure out all the
logic again and come up with a proper fix.

By the way, this is really good news that MSVC found this issue and
you reported it because previously I was having trouble figuring out
why that code was not producing correct superscript/subscript results.
But I suspect once I fix this uninitialized variable bug, that other
problem will become understandable and solveable as well.

> By the way, the correct 64-bits libraries are installed in a
directory containing the "x64" suffix. So my earlier change was (a)
not necessary (b) an indication I had downloaded the wrong libraries.
If only they had used "x86" or "x32" or something for 32-bits versions
...

So it sounds like you want to drop your previous commit to
cmake/modules/FindwxWidgets.cmake.

If that is the case, please do that immediately while you remember
these recent find troubles.  However, the quick git lesson is you
should not destroy your previous commit like you can with a private
topic branch commit that has not yet been published since the
offending commit you don't like any more is published (meaning others
should be able to count on it remaining on our public repository
indefinitely).  So instead locally reverse the changes you made to
cmake/modules/FindwxWidgets.cmake on a private topic branch. And
commit that change (with good explanatory commit message) on that
private topic branch and then merge it to master in our public
repository using our usual workflow.

So the net result is you get credit for two public commits this way;
your original one and then another separate commit to reverse it.
So it is a win-win similar to my forthcoming fix for the above
uninitialized variable error.  :-)

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-11 13:42+0200 Ole Streicher wrote:

> Dear Alan,
>
> thank you very much for your quick (and very positive) answer!
> Concerning the upstream changes: you could for the moment just drop the
> "debian/" subdir. It will be replaced anyway during the packaging
> process, and therefore no longer maintained in your git and may be
> misleading for others. For any other changes, I need to look through and
> will come back when I have proposals.

Hi Ole:

With regard to the above Debian "issue":

I agree this confusion between upstream and Debian is not ideal.
However, Debian packaging is important to us since it does reveal some
deficiencies (at least from the Debian point of view) with the
upstream version.  And I do have sufficient Debian packaging knowledge
that I can interpret a debian subdirectory tree even if I don't have
sufficient knowledge to create one on my own.  So I think the best
thing to do is to replace everything in our now out-dated debian
subdirectory with a README that shows how to get convenient access to
the latest debian packaging information that you are working on. So I
would appreciate you supplying that information, and once I have that
from you, I will make that proposed change.

>
> For the csiro license problem:
>
> On 11.07.2017 12:59, Alan W. Irwin wrote:
>> Apparently there is licensing text for the full modern versions of
>> nn and csa at <https://github.com/sakov/nn-c/blob/master/nn/LICENSE>
>> and <https://github.com/sakov/csa-c/blob/master/csa/LICENSE>. I am
>> not a license lawyer, but the latter looks like a simple free
>> software license to me. If you agree, and, better yet, if you can
>> identify what free license it is (some form of BSD??), then it is
>> likely it is license that you will be able to immediately identify as
>> consistent with Debian's DFSG.
>
> This is a kind-of simplified BSD-3-Clause license, as f.e. this one:
>
> https://spdx.org/licenses/BSD-3-Clause
>
> The difference is mainly that the original second condition is
> removed/merged into the first one, and the third is then renumbered to
> be the second.

Our e-mails crossed, but it appears we independently arrived at that
same conclusion.

>
>> In which case, it should be a simple matter regardless of whatever
>> agreement he made with Rafael in 2003+ to convince Pavel to license
>> our stripped version for both nn and csa that we adopted in 2003
>> under that same free software license.
>
> If PLplot can use the modern versions of the library source (or the
> first version from 2009 on github [1]), yes. IMO that would be the
> simplest way.

The issue with that solution is Pavel's unstripped version of nn has
consistently used un-free triangle forever and Joao immediately
switched the stripped version to use the free qhull library instead.
But if ever Pavel made the decision to switch from his triangle
dependency to a free library like qhull, then presumably it would be
possible for us to adjust PLplot to use (and presumably distribute)
that modern nn library ourselves under that modified but
DSFG-compliant variant of the 3-clause BSD license currently used for
modern csa.  But in any case I would prefer not to do that work (and
similarly for adjusting us to the full modern csa library) since the
stripped down versions have been fine for our needs all these years.

>> In sum, I think to deal with this licensing issue, the following 4
>> steps are needed:
>>
>> 1. Identify the modern full csa licensing from the above text.  In
>> the following steps I assume you will be able to identify it as a
>> well-known free software license that is already known to be
>> compatible with the DFSG.
>
> It is, for sure. However, not a common one (as far as I know).

That is good news that Debian would be happy with that license
assuming we are allowed by Pavel to adopt it.

>
>> 2. Find a modern e-mail address for Pavel (surely github provides
>> that in some way, but I cannot find it).
>
> I just cloned the repository and looked into his commits :-) There is
> one real E-mail address: <pav...@gm...>. This also f.e. appears
> in the README of the enkf-c repository.

Thanks! I should have thought of git as the best tool for getting a
reliable e-mail address.  :-)

>
>> 3. Ask Pavel to allow us to relicense the stripped version of nn and
>> csa that we adopted in 2003 [...]
>
>> 4. Upstream change: Remove the misleading lib/nn/README and
>> lib/csa/README files and replace those with lib/nn/LICENSE and
>> lib/csa/LICENSE [...]
>
>> If you are willing to deal with the first two of these issues I am
>> willing to deal with the third and fourth, but if you would also
>> like to follow through with the third as well (quoting any part of
>> this e-mail you feel is relevant) that would be even more helpful!
>> In sum, I am looking forward with your help to finishing the above
>> steps to remove completely the licensing uncertainty for these two
>> PLplot libraries.
>
> Would you contact him? This may be even better since I am just coming
> from aside (and you know more about the history of the inclusion of his
> libraries). If the gmail address doest not work, you could even just
> open an issue in the nn-c or csa-c library to get in contact.
>
> I am however quite happy that the problems seems to be solvable that easy!

OK. Thanks very much for confirming the modern csa license is
DSFG-compliant and for finding Pavel's modern e-mail address.

I will follow up soon by contacting Pavel at the gmail address you
found above with a CC to you, and we will see what he says.

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] The wxwidgets version you use for MSVC - solved (not quite though)

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

Hi Alan, Phil,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, July 10, 2017 11:36 PM
>
> Anyhow, I now think you have had all the input you need from Phil and me to fix or
> work around this wxwidgets linking issue you have discovered, and I look forward to
> hearing from you what the solution turns out to be.
>
I use VERBOSE=1 to get insight in the build process, but that was of little use - most of the details are hidden in temporary files. So I checked the dependencies file (CXX.includecache) and saw only include files from d:\wxwidgets. Then I compiled the source file using the flags in flags.make and the -E option to get the preprocessed source and found that both wxString and wxSize were defined as expected (and used all over the place). So I sought the .lib files (so-called import libraries) for the symbols that were missing. None contained exactly those strings.

Okay, I went back to the wxWidgets site, downloaded the latest version (as that was advertised). Exact same problem. Then I noticed something - there were separate distributions for 32 bits and 64 bits environments. And then it hit me: I had downloaded the _wrong_ bits version. From there on it went quite smoothly. After some struggles with the path I got the build to succeed and got an example to run. The only (!) problem left is that on line 378 in wxwidgets_dev.cpp the variable "offset" is used but was not previously set. This causes a debug error under MSVC:

[cid:image001.png@01D2FA8F.0E63E220]

A quick check of the source code did not tell me how to solve that, so I will have to leave that to you.

By the way, the correct 64-bits libraries are installed in a directory containing the "x64" suffix. So my earlier change was (a) not necessary (b) an indication I had downloaded the wrong libraries. If only they had used "x86" or "x32" or something for 32-bits versions ...

Regards,

Arjen

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

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-11 03:59-0700 Alan W. Irwin wrote:

[...]
<https://github.com/sakov/csa-c/blob/master/csa/LICENSE>
[...]

> 1. Identify the modern full csa licensing from the above text.  In the
>   following steps I assume you will be able to identify it as a
>   well-known free software license that is already known to be
>   compatible with the DFSG.

My further google searching has found the above modern csa license
text is likely an older variant of the latest 3-clause BSD license
<https://www.freebsd.org/internal/software-license.html> where the
variation is fundamentally to merge the first two clauses together so
as not to distinguish between source and binary redistribution.
Because this variant is not an exact official free software license
(as far as I can tell) it presumably makes your job a little harder to
satisfy yourself that it is DFSG compliant, but I remain confident
(because it seems close in spirit to the 3-clause BSD) you will be
able to do that.

Alan

>
> 2. Find a modern e-mail address for Pavel (surely github provides that
>   in some way, but I cannot find it).
>
> 3. Ask Pavel to allow us to relicense the stripped version of nn and
>   csa that we adopted in 2003 (and which does not depend on the
>   proprietary triangle software due to Joao's further modifications)
>   with the free software license you have identified in the first
>   step above.  Alternatively, if it turns out the above modern
>   licensing text for csa is not DFSG compatible, then ask Pavel
>   to relicense our stripped version under the LGPL.  Frankly, I
>   would be surprised if he objected to either request, but to
>   be clear I prefer the license above (if suitable) for
>   our stripped version just to be consistent with the modern
>   nn and csa licensing as much as possible (i.e., with
>   the triangle note dropped).
>
> 4. Upstream change: Remove the misleading lib/nn/README and
>   lib/csa/README files and replace those with lib/nn/LICENSE and
>   lib/csa/LICENSE which are both consistent with the text in
>   <https://github.com/sakov/csa-c/blob/master/csa/LICENSE> (or the
>   LGPL if your research shows the above modern license is not DFSG
>   compatible).
>
> If you are willing to deal with the first two of these issues I am
> willing to deal with the third and fourth, but if you would also like
> to follow through with the third as well (quoting any part of this
> e-mail you feel is relevant) that would be even more helpful!  In sum,
> I am looking forward with your help to finishing the above steps to
> remove completely the licensing uncertainty for these two PLplot
> libraries.

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Dear Alan,

thank you very much for your quick (and very positive) answer!
Concerning the upstream changes: you could for the moment just drop the
"debian/" subdir. It will be replaced anyway during the packaging
process, and therefore no longer maintained in your git and may be
misleading for others. For any other changes, I need to look through and
will come back when I have proposals.

For the csiro license problem:

On 11.07.2017 12:59, Alan W. Irwin wrote:
> Apparently there is licensing text for the full modern versions of
> nn and csa at <https://github.com/sakov/nn-c/blob/master/nn/LICENSE>
> and <https://github.com/sakov/csa-c/blob/master/csa/LICENSE>. I am
> not a license lawyer, but the latter looks like a simple free
> software license to me. If you agree, and, better yet, if you can
> identify what free license it is (some form of BSD??), then it is
> likely it is license that you will be able to immediately identify as
> consistent with Debian's DFSG.

This is a kind-of simplified BSD-3-Clause license, as f.e. this one:

https://spdx.org/licenses/BSD-3-Clause

The difference is mainly that the original second condition is
removed/merged into the first one, and the third is then renumbered to
be the second.

> In which case, it should be a simple matter regardless of whatever
> agreement he made with Rafael in 2003+ to convince Pavel to license
> our stripped version for both nn and csa that we adopted in 2003
> under that same free software license.

If PLplot can use the modern versions of the library source (or the
first version from 2009 on github [1]), yes. IMO that would be the
simplest way.

> One minor complication is that the modern nn license text which is 
> otherwise completely compatible with the modern csa license text has 
> an additional note on the end as follows:
> 
> Note: this software makes use of the Triangle software, which is 
> non-free for commercial use. See the triangle.c and triangle.h files 
> for details.

I would just remove it :-) Formal reason is that the license requires to
keep only the three parts of the original license, and also I would not
take the Note as part of the license at all. And pragmatically, since
you don't use triangle.[ch].

> In sum, I think to deal with this licensing issue, the following 4
> steps are needed:
> 
> 1. Identify the modern full csa licensing from the above text.  In
> the following steps I assume you will be able to identify it as a 
> well-known free software license that is already known to be 
> compatible with the DFSG.

It is, for sure. However, not a common one (as far as I know).

> 2. Find a modern e-mail address for Pavel (surely github provides
> that in some way, but I cannot find it).

I just cloned the repository and looked into his commits :-) There is
one real E-mail address: <pav...@gm...>. This also f.e. appears
in the README of the enkf-c repository.

> 3. Ask Pavel to allow us to relicense the stripped version of nn and 
> csa that we adopted in 2003 [...]

> 4. Upstream change: Remove the misleading lib/nn/README and 
> lib/csa/README files and replace those with lib/nn/LICENSE and 
> lib/csa/LICENSE [...]

> If you are willing to deal with the first two of these issues I am 
> willing to deal with the third and fourth, but if you would also
> like to follow through with the third as well (quoting any part of
> this e-mail you feel is relevant) that would be even more helpful!
> In sum, I am looking forward with your help to finishing the above
> steps to remove completely the licensing uncertainty for these two
> PLplot libraries.

Would you contact him? This may be even better since I am just coming
from aside (and you know more about the history of the inclusion of his
libraries). If the gmail address doest not work, you could even just
open an issue in the nn-c or csa-c library to get in contact.

I am however quite happy that the problems seems to be solvable that easy!

Best regards

Ole

[1]
https://github.com/sakov/nn-c/tree/71a59e6a

Re: [Plplot-devel] PLplot Debian package

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

Hi Ole:

Thanks for getting in touch with us concerning the Debian packaging of
PLplot. Andrew Ross (who at one time maintained Debian packaging of
PLplot) is our only Debian packaging expert.  But he has been inactive
in PLplot development for a while now so it is likely our help to you
will be limited to making upstream changes to minimize the number of
patches you have to apply and also making upstream changes to
straighten out any licensing uncertainties (see below).

On 2017-07-11 09:43+0200 Ole Streicher wrote:

> The other point is already older, but a show-stopper: PLplot uses a few
> old libraries from Pavel Sakov (CSIRO Marine Research), in lib/csa and
> lib/nn. These libraries have a license that is not free (in the sense of
> the Debian Free Software Guidelines [3]), and they are incompatible to
> the LGPL of plplot. I already wrote an E-mail to the mail address given
> in the README to ask him for a license change, but I am not sure whether
> Pavel's address is still valid.
>
> There was already some discussion on Debian mailing lists about that
> topic 9 years ago [4], but I couldn't find a (follow-up) discussion on
> the plplot-devel mailing list. Was there any discussion, and what is
> your opinion about that license?

Your help with solving this licensing uncertainty (which I have not
been too concerned about before due to historical reassurances from
Rafael Laboissiere) would be much appreciated.

When this topic first came up soon after we starting using stripped
versions of Pavel's csa and nn libraries back in 2003 Rafael
Laboissiere (who was a fanatic about free software licensing)
contacted Pavel privately and afterward assured us the licensing issue
was settled (I think by getting Pavel's OK to relicense our stripped
version of his work under the LGPL, but I am by no means sure about
that).  However, after that reassurance Rafael never changed our
lib/nn/README and lib/csa/README files to reflect whatever that 2003+
agreement with Pavel was. Therefore, I agree, the issue is at least
formally still with us. And since then Rafael has completely dropped
out of the Debian world and the free software world (including PLplot)
after supporting both so strongly for so many years.  So Rafael is no
longer a good contact concerning this situation.

Do you know how to extract e-mail contact information from github?  If
so, Pavel is active on github and apparently still working on the full
versions of both nn and csa. (see
<https://github.com/sakov?tab=overview&from=2017-05-01&to=2017-05-31&utf8=%E2%9C%93>)

Apparently there is licensing text for the full modern versions of nn
and csa at <https://github.com/sakov/nn-c/blob/master/nn/LICENSE> and
<https://github.com/sakov/csa-c/blob/master/csa/LICENSE>. I am not a
license lawyer, but the latter looks like a simple free software
license to me. If you agree, and, better yet, if you can identify what
free license it is (some form of BSD??), then it is likely it is
license that you will be able to immediately identify as consistent
with Debian's DFSG.  In which case, it should be a simple matter
regardless of whatever agreement he made with Rafael in 2003+ to
convince Pavel to license our stripped version for both nn and csa
that we adopted in 2003 under that same free software license.

One minor complication is that the modern nn license text which is
otherwise completely compatible with the modern csa license text has
an additional note on the end as follows:

Note: this software makes use of the Triangle software, which is
non-free for commercial use. See the triangle.c and triangle.h files
for details.

Our own file, lib/nn/README refers to this same "triangle" issue in a different
way.

However, I don't think we have to be concerned about that issue in the
slightest since our stripped version lib/nn contains no triangle.c or
triangle.h and lib/nn/delaunay.c contains the following comment line

//                 Adapted for use with Qhull instead of "triangle".

which I traced back using git blame --follow to

b583d184 (Joao Cardoso      2003-03-02 02:04:52 +0000  20)  *      Adapted for use with Qhull instead of "triangle"

The associated commit message for b583d184 was

Add a striped version of Pavel Sakov nn library to support Delaunay
linear interpolation and Natural Neighbors interpolation for
plgridata().

Note, although apparently Joao was smart enough to get rid of the
dependence on "triangle", he has long since retired from the free
software world so he is also not a good contact concerning this
situation.

In sum, I think to deal with this licensing issue, the following 4 steps
are needed:

1. Identify the modern full csa licensing from the above text.  In the
    following steps I assume you will be able to identify it as a
    well-known free software license that is already known to be
    compatible with the DFSG.

2. Find a modern e-mail address for Pavel (surely github provides that
    in some way, but I cannot find it).

3. Ask Pavel to allow us to relicense the stripped version of nn and
    csa that we adopted in 2003 (and which does not depend on the
    proprietary triangle software due to Joao's further modifications)
    with the free software license you have identified in the first
    step above.  Alternatively, if it turns out the above modern
    licensing text for csa is not DFSG compatible, then ask Pavel
    to relicense our stripped version under the LGPL.  Frankly, I
    would be surprised if he objected to either request, but to
    be clear I prefer the license above (if suitable) for
    our stripped version just to be consistent with the modern
    nn and csa licensing as much as possible (i.e., with
    the triangle note dropped).

4. Upstream change: Remove the misleading lib/nn/README and
    lib/csa/README files and replace those with lib/nn/LICENSE and
    lib/csa/LICENSE which are both consistent with the text in
    <https://github.com/sakov/csa-c/blob/master/csa/LICENSE> (or the
    LGPL if your research shows the above modern license is not DFSG
    compatible).

If you are willing to deal with the first two of these issues I am
willing to deal with the third and fourth, but if you would also like
to follow through with the third as well (quoting any part of this
e-mail you feel is relevant) that would be even more helpful!  In sum,
I am looking forward with your help to finishing the above steps to
remove completely the licensing uncertainty for these two PLplot
libraries.

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] PLplot Debian package

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

Hi,

I am a member of the Debian Astro and Debian Science teams.

As you may know, PLplot has a Debian package that was also shipped with
the latest Debian release [1]. However, the package is outdated and not
properly maintained anymore, and so our MIA team decided to "orphan" the
package [2], which means that it needs a new maintainer.

Since PLplot is a dependency of a number of astronomy packages, I
decided to take over the maintenance of PLplot, and to put it under
Debian Science team maintenance. This basically means that the Debian
specific files are going to be maintained on the Debian infrastructure
<https://anonscm.debian.org/cgit/debian-science/packages/plplot.git>
instead of being part of the original tarball.

The reason is that we want to have an easy way to change the
Debian files if needed. For example, in preparation of the last Debian
release, we already needed to apply some changes, which are now not
reflected in the original PLplot git repository.

What I already did with PLplot is to change the Debian packaging
structure (git branches, patches) to use the "git-buildpackage" way of
building Debian packages, and to update to the latest PLplot version
(5.12.0). The next step is to simplify the structure of the Debian
specific files and to update them for the latest tools that help to
build debian packages, and to fix the Debian specific bugs that popped
up in the last years.

My first question is now if there is a volunteer to help or even take
over the maintenance of the package. The volunteer should join the
Debian Science team for the packaging. If someone wants to take over, we
will help if there are any problems with the packaging. If you want to
help, please contact me; by directly by e-mail, or via our mailing list
<deb...@li...>.

The other point is already older, but a show-stopper: PLplot uses a few
old libraries from Pavel Sakov (CSIRO Marine Research), in lib/csa and
lib/nn. These libraries have a license that is not free (in the sense of
the Debian Free Software Guidelines [3]), and they are incompatible to
the LGPL of plplot. I already wrote an E-mail to the mail address given
in the README to ask him for a license change, but I am not sure whether
Pavel's address is still valid.

There was already some discussion on Debian mailing lists about that
topic 9 years ago [4], but I couldn't find a (follow-up) discussion on
the plplot-devel mailing list. Was there any discussion, and what is
your opinion about that license?

If you have other comments on the Debian packaging, I would be also very
glad to hear from you.

Best regards

Ole

[1] https://tracker.debian.org/pkg/plplot
[2] https://bugs.debian.org/867049
[3] https://www.debian.org/social_contract#guidelines
[4] https://lists.debian.org/debian-legal/2008/10/msg00002.html

Re: [Plplot-devel] The wxwidgets version you use for MSVC

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

Hi Alan, Phil,



Thanks for all the input and suggestions. I will try and find time this evening to hunt down the cause of these problems.

Regards,

Arjen


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, July 10, 2017 11:36 PM
> To: Arjen Markus; Phil Rosenberg; plp...@li...
> Subject: Re: [Plplot-devel] The wxwidgets version you use for MSVC
>
> On 2017-07-10 11:20-0700 Alan W. Irwin wrote:
>
> > On 2017-07-10 11:05-0000 Arjen Markus wrote:
> >
> > [...]
> >> As far as I can tell, the build should be picking up everything from
> > the installation and not gather stuff from elsewhere. It is unlikely
> > it is scavenging the MinGW or Cywin installations. Anyway, got to
> > check that.
> >
> > Hi Arjen:
> >
> > I assume you are going to do that check using the nmake VERBOSE=1
> > option to discover the actual -I options your PLplot build uses for
> > the wxwidgets components.  At the same time you should check whether
> > those -I options refer to locations that are too deep into the
> > wxwidgets header tree so you are finding a private header rather than
> > the correct public version of the header.  And another option is for
> > you to try a wxwidgets version that you built yourself with the exact
> > build options you need in case that makes any difference. So there
> > appears to be plenty of things you can try here to help you find the
> > solution to the MSVC link error you discovered.
>
> Hi again, Arjen:
>
> Although it would be good to quickly check the above possibility that CMake might
> incorrectly find a private header rather than the desired public header, I now think
> the probability of that happening is low.
> The reason is the official version of the find module is heavily maintained (and
> therefore likely to get the -I options right).
> Furthermore, I have also checked all our changes to
> cmake/modules/FindwxWidgets.cmake relative to the official version, and they are
> completely straightforward and have nothing to do with -I options.
>
> Anyhow, I now think you have had all the input you need from Phil and me to fix or
> work around this wxwidgets linking issue you have discovered, and I look forward to
> hearing from you what the solution turns out to be.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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

Re: [Plplot-devel] The wxwidgets version you use for MSVC

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

On 2017-07-10 11:20-0700 Alan W. Irwin wrote:

> On 2017-07-10 11:05-0000 Arjen Markus wrote:
>
> [...]
>> As far as I can tell, the build should be picking up everything from
> the installation and not gather stuff from elsewhere. It is unlikely
> it is scavenging the MinGW or Cywin installations. Anyway, got to
> check that.
>
> Hi Arjen:
>
> I assume you are going to do that check using the nmake VERBOSE=1
> option to discover the actual -I options your PLplot build uses for
> the wxwidgets components.  At the same time you should check whether
> those -I options refer to locations that are too deep into the
> wxwidgets header tree so you are finding a private header rather than
> the correct public version of the header.  And another option is for
> you to try a wxwidgets version that you built yourself with the exact
> build options you need in case that makes any difference. So there
> appears to be plenty of things you can try here to help you find the
> solution to the MSVC link error you discovered.

Hi again, Arjen:

Although it would be good to quickly check the above possibility that
CMake might incorrectly find a private header rather than the desired
public header, I now think the probability of that happening is low.
The reason is the official version of the find module is heavily
maintained (and therefore likely to get the -I options right).
Furthermore, I have also checked all our changes to
cmake/modules/FindwxWidgets.cmake relative to the official version,
and they are completely straightforward and have nothing to do with -I
options.

Anyhow, I now think you have had all the input you need from Phil and
me to fix or work around this wxwidgets linking issue you have
discovered, and I look forward to hearing from you what the solution
turns out to be.

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] The wxwidgets version you use for MSVC

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

On 2017-07-10 11:05-0000 Arjen Markus wrote:

[...]
> As far as I can tell, the build should be picking up everything from
the installation and not gather stuff from elsewhere. It is unlikely
it is scavenging the MinGW or Cywin installations. Anyway, got to
check that.

Hi Arjen:

I assume you are going to do that check using the nmake VERBOSE=1
option to discover the actual -I options your PLplot build uses for
the wxwidgets components.  At the same time you should check whether
those -I options refer to locations that are too deep into the
wxwidgets header tree so you are finding a private header rather than
the correct public version of the header.  And another option is for
you to try a wxwidgets version that you built yourself with the exact
build options you need in case that makes any difference. So there
appears to be plenty of things you can try here to help you find the
solution to the MSVC link error you discovered.

Good luck during this hunt for the solution!

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] The wxwidgets version you use for MSVC

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

Hi Phil,



I will have to check that later. As far as I can tell, the build should be picking up everything from the installation and not gather stuff from elsewhere. It is unlikely it is scavenging the MinGW or Cywin installations. Anyway, got to check that.



Regards,



Arjen



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
> Sent: Monday, July 10, 2017 12:31 PM
> To: Arjen Markus; Alan W. Irwin; plp...@li...
> Subject: Re: The wxwidgets version you use for MSVC
>
> Last email of speculation
>
> I have found in the latest source that the file include/wx/gdicmn.h includes the inline
> definition for the constructor, but the file interface/wx/gdicmn.h does not include the
> inline definition for the constructor. The former should be used by external
> applications like ours, the latter is for building the wx libraries themselves. Is it
> possible that you are loading the latter somehow from somewhere?
>
> On 10 July 2017 at 11:18, Phil Rosenberg <p.d...@gm...> wrote:
> > Hi Arjen
> > Doing a git blame on GitHub indicates that the relevant constructor
> > line was last edited 10 years ago, which seems strange. However that
> > is probably the header used when building the library rather than put
> > in the include directory for use by external programs. Maybe the two
> > are not the same :-s.
> >
> > If you are building with Visual studio, then you can find an example
> > of wxSize being used and right click it, then go to
> > definition/declaration. This should take you to the actual header file
> > being parsed and you can check it is the one you expect (hover over
> > the filename tab to show the full path or right click the tab and hit
> > open containing folder) and you can check the constructor is inlined.
> >
> > Phil
> >
> > On 10 July 2017 at 11:10, Arjen Markus <Arj...@de...> wrote:
> >> Hi Phil,
> >>
> >>
> >>
> >> I am using MSVC and nmake to compile this under bare Windows. I
> >> remember seeing some confusion over what installation CMake came up
> >> with exactly, but I do not recall the details. That may have been with the MinGW
> experiments.
> >>
> >>
> >>
> >> I will have to check this - tonight if possible.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Arjen
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Phil Rosenberg [mailto:p.d...@gm...]
> >>
> >>> Sent: Monday, July 10, 2017 12:04 PM
> >>> To: Arjen Markus
> >>> Subject: Re: The wxwidgets version you use for MSVC
> >>>
> >>> Ah, so you do have the inlined function definition. In that case I
> >>> am confused.
> >>>
> >>> Is there any possibility that you have more than one set of
> >>> wxWidgets headers installed, the one you are looking at and a latest
> >>> dev version?
> >>>
> >>> What are you using to compile are you using visual studio or minGW?
> >>>
> >>> Phil
> >>>
> >>> On 10 July 2017 at 10:52, Arjen Markus <Arj...@de...> wrote:
> >>> > Hi Phil,
> >>> >
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Phil Rosenberg [mailto:p.d...@gm...]
> >>> >> Sent: Monday, July 10, 2017 11:49 AM
> >>> >> To: Arjen Markus; plp...@li...
> >>> >> Cc: Alan W. Irwin
> >>> >> Subject: Re: The wxwidgets version you use for MSVC
> >>> >>
> >>> >> Hi Arjen
> >>> >> That looks like the class you are looking for. Those comments
> >>> >> shouldn't be important. They just mean that you can access x and
> >>> >> y exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
> >>> >> But the comment says please don't do this.
> >>> >>
> >>> >
> >>> > Right, I misread that as meaning the data AND the method members,
> >>> > but it only refers to the data members.
> >>> >
> >>> >> Further down in that class is there a constructor? it will look
> >>> >> something like wxSize( int w, int h). It looks like a function
> >>> >> declaration, but with no return type. The variable names may be
> >>> >> different too - probably some variation on width and height or x
> >>> >> and y.
> >>> >>
> >>> > There are two in fact:
> >>> >
> >>> >     // constructors
> >>> >
> >>> >     wxSize() : x(0), y(0) { }
> >>> >
> >>> >     wxSize(int xx, int yy) : x(xx), y(yy) { }
> >>> >
> >>> > Regards,
> >>> >
> >>> > Arjen
> >>> >
> >>> > DISCLAIMER: This message is intended exclusively for the
> >>> > addressee(s) and may contain confidential and privileged
> >>> > information. If you are not the intended recipient please notify
> >>> > the sender immediately and destroy this message. Unauthorized use,
> >>> > disclosure or copying of this message is strictly prohibited. The
> >>> > foundation 'Stichting Deltares', which has its seat at Delft, The
> >>> > Netherlands, Commercial Registration Number 41146461, is not
> >>> > liable in any way whatsoever for consequences and/or damages
> >>> > resulting from the improper, incomplete and untimely dispatch, receipt and/or
> content of this e-mail.
> >>
> >> DISCLAIMER: This message is intended exclusively for the addressee(s)
> >> and may contain confidential and privileged information. If you are
> >> not the intended recipient please notify the sender immediately and
> >> destroy this message. Unauthorized use, disclosure or copying of this
> >> message is strictly prohibited. The foundation 'Stichting Deltares',
> >> which has its seat at Delft, The Netherlands, Commercial Registration
> >> Number 41146461, is not liable in any way whatsoever for consequences
> >> and/or damages resulting from the improper, incomplete and untimely
> >> dispatch, receipt and/or content of this e-mail.
>

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] The wxwidgets version you use for MSVC

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

Last email of speculation

I have found in the latest source that the file include/wx/gdicmn.h
includes the inline definition for the constructor, but the file
interface/wx/gdicmn.h does not include the inline definition for the
constructor. The former should be used by external applications like
ours, the latter is for building the wx libraries themselves. Is it
possible that you are loading the latter somehow from somewhere?

On 10 July 2017 at 11:18, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Arjen
> Doing a git blame on GitHub indicates that the relevant constructor
> line was last edited 10 years ago, which seems strange. However that
> is probably the header used when building the library rather than put
> in the include directory for use by external programs. Maybe the two
> are not the same :-s.
>
> If you are building with Visual studio, then you can find an example
> of wxSize being used and right click it, then go to
> definition/declaration. This should take you to the actual header file
> being parsed and you can check it is the one you expect (hover over
> the filename tab to show the full path or right click the tab and hit
> open containing folder) and you can check the constructor is inlined.
>
> Phil
>
> On 10 July 2017 at 11:10, Arjen Markus <Arj...@de...> wrote:
>> Hi Phil,
>>
>>
>>
>> I am using MSVC and nmake to compile this under bare Windows. I remember
>> seeing some confusion over what installation CMake came up with exactly, but
>> I do not recall the details. That may have been with the MinGW experiments.
>>
>>
>>
>> I will have to check this – tonight if possible.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>> -----Original Message-----
>>> From: Phil Rosenberg [mailto:p.d...@gm...]
>>
>>> Sent: Monday, July 10, 2017 12:04 PM
>>> To: Arjen Markus
>>> Subject: Re: The wxwidgets version you use for MSVC
>>>
>>> Ah, so you do have the inlined function definition. In that case I am
>>> confused.
>>>
>>> Is there any possibility that you have more than one set of wxWidgets
>>> headers
>>> installed, the one you are looking at and a latest dev version?
>>>
>>> What are you using to compile are you using visual studio or minGW?
>>>
>>> Phil
>>>
>>> On 10 July 2017 at 10:52, Arjen Markus <Arj...@de...> wrote:
>>> > Hi Phil,
>>> >
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Phil Rosenberg [mailto:p.d...@gm...]
>>> >> Sent: Monday, July 10, 2017 11:49 AM
>>> >> To: Arjen Markus; plp...@li...
>>> >> Cc: Alan W. Irwin
>>> >> Subject: Re: The wxwidgets version you use for MSVC
>>> >>
>>> >> Hi Arjen
>>> >> That looks like the class you are looking for. Those comments
>>> >> shouldn't be important. They just mean that you can access x and y
>>> >> exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
>>> >> But the comment says please don't do this.
>>> >>
>>> >
>>> > Right, I misread that as meaning the data AND the method members, but
>>> > it only refers to the data members.
>>> >
>>> >> Further down in that class is there a constructor? it will look
>>> >> something like wxSize( int w, int h). It looks like a function
>>> >> declaration, but with no return type. The variable names may be
>>> >> different too - probably some variation on width and height or x and
>>> >> y.
>>> >>
>>> > There are two in fact:
>>> >
>>> >     // constructors
>>> >
>>> >     wxSize() : x(0), y(0) { }
>>> >
>>> >     wxSize(int xx, int yy) : x(xx), y(yy) { }
>>> >
>>> > Regards,
>>> >
>>> > Arjen
>>> >
>>> > DISCLAIMER: This message is intended exclusively for the addressee(s)
>>> > and may contain confidential and privileged information. If you are
>>> > not the intended recipient please notify the sender immediately and
>>> > destroy this message. Unauthorized use, disclosure or copying of this
>>> > message is strictly prohibited. The foundation 'Stichting Deltares',
>>> > which has its seat at Delft, The Netherlands, Commercial Registration
>>> > Number 41146461, is not liable in any way whatsoever for consequences
>>> > and/or damages resulting from the improper, incomplete and untimely
>>> > dispatch, receipt and/or content of this e-mail.
>>
>> DISCLAIMER: This message is intended exclusively for the addressee(s) and
>> may contain confidential and privileged information. If you are not the
>> intended recipient please notify the sender immediately and destroy this
>> message. Unauthorized use, disclosure or copying of this message is strictly
>> prohibited. The foundation 'Stichting Deltares', which has its seat at
>> Delft, The Netherlands, Commercial Registration Number 41146461, is not
>> liable in any way whatsoever for consequences and/or damages resulting from
>> the improper, incomplete and untimely dispatch, receipt and/or content of
>> this e-mail.

Re: [Plplot-devel] The wxwidgets version you use for MSVC

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

Hi Arjen
Doing a git blame on GitHub indicates that the relevant constructor
line was last edited 10 years ago, which seems strange. However that
is probably the header used when building the library rather than put
in the include directory for use by external programs. Maybe the two
are not the same :-s.

If you are building with Visual studio, then you can find an example
of wxSize being used and right click it, then go to
definition/declaration. This should take you to the actual header file
being parsed and you can check it is the one you expect (hover over
the filename tab to show the full path or right click the tab and hit
open containing folder) and you can check the constructor is inlined.

Phil

On 10 July 2017 at 11:10, Arjen Markus <Arj...@de...> wrote:
> Hi Phil,
>
>
>
> I am using MSVC and nmake to compile this under bare Windows. I remember
> seeing some confusion over what installation CMake came up with exactly, but
> I do not recall the details. That may have been with the MinGW experiments.
>
>
>
> I will have to check this – tonight if possible.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>> -----Original Message-----
>> From: Phil Rosenberg [mailto:p.d...@gm...]
>
>> Sent: Monday, July 10, 2017 12:04 PM
>> To: Arjen Markus
>> Subject: Re: The wxwidgets version you use for MSVC
>>
>> Ah, so you do have the inlined function definition. In that case I am
>> confused.
>>
>> Is there any possibility that you have more than one set of wxWidgets
>> headers
>> installed, the one you are looking at and a latest dev version?
>>
>> What are you using to compile are you using visual studio or minGW?
>>
>> Phil
>>
>> On 10 July 2017 at 10:52, Arjen Markus <Arj...@de...> wrote:
>> > Hi Phil,
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Phil Rosenberg [mailto:p.d...@gm...]
>> >> Sent: Monday, July 10, 2017 11:49 AM
>> >> To: Arjen Markus; plp...@li...
>> >> Cc: Alan W. Irwin
>> >> Subject: Re: The wxwidgets version you use for MSVC
>> >>
>> >> Hi Arjen
>> >> That looks like the class you are looking for. Those comments
>> >> shouldn't be important. They just mean that you can access x and y
>> >> exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
>> >> But the comment says please don't do this.
>> >>
>> >
>> > Right, I misread that as meaning the data AND the method members, but
>> > it only refers to the data members.
>> >
>> >> Further down in that class is there a constructor? it will look
>> >> something like wxSize( int w, int h). It looks like a function
>> >> declaration, but with no return type. The variable names may be
>> >> different too - probably some variation on width and height or x and
>> >> y.
>> >>
>> > There are two in fact:
>> >
>> >     // constructors
>> >
>> >     wxSize() : x(0), y(0) { }
>> >
>> >     wxSize(int xx, int yy) : x(xx), y(yy) { }
>> >
>> > Regards,
>> >
>> > Arjen
>> >
>> > DISCLAIMER: This message is intended exclusively for the addressee(s)
>> > and may contain confidential and privileged information. If you are
>> > not the intended recipient please notify the sender immediately and
>> > destroy this message. Unauthorized use, disclosure or copying of this
>> > message is strictly prohibited. The foundation 'Stichting Deltares',
>> > which has its seat at Delft, The Netherlands, Commercial Registration
>> > Number 41146461, is not liable in any way whatsoever for consequences
>> > and/or damages resulting from the improper, incomplete and untimely
>> > dispatch, receipt and/or content of this e-mail.
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

Re: [Plplot-devel] The wxwidgets version you use for MSVC

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

Hi Phil,



Quite the same - see my earlier reply.



Regards,



Arjen



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
> Sent: Monday, July 10, 2017 12:02 PM
> To: Arjen Markus; plp...@li...
> Cc: Alan W. Irwin
> Subject: Re: The wxwidgets version you use for MSVC
>
> I just checked in my version. I have
>
> class WXDLLIMPEXP_CORE wxSize
> {
> public:
>     // members are public for compatibility, don't use them directly.
>     int x, y;
>     // constructors
>     wxSize() : x(0), y(0) { }
>     wxSize(int xx, int yy) : x(xx), y(yy) { }
>
> The last line is the important one. What does it look like in your version?
>
> I have just looked on GitHub on the latest source
> (https://github.com/wxWidgets/wxWidgets/blob/master/interface/wx/gdicmn.h)
> and this constructor has indeed changed to not inlined and instead looks like
>
> wxSize(int width, int height);
>
> I would suggest that there is some mismatch between the headers you have and
> the dll. The dll used inlined version, so includes no definition and the headers have
> the non inlined version so also includes no definition. The linker is therefore
> rightfully complaining there is no definition. If this is the case then it's a bug with the
> wxWidgets distribution.
>
> Phil
>
> On 10 July 2017 at 10:48, Phil Rosenberg <p.d...@gm...> wrote:
> > Hi Arjen
> > That looks like the class you are looking for. Those comments
> > shouldn't be important. They just mean that you can access x and y
> > exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
> > But the comment says please don't do this.
> >
> > Further down in that class is there a constructor? it will look
> > something like wxSize( int w, int h). It looks like a function
> > declaration, but with no return type. The variable names may be
> > different too - probably some variation on width and height or x and
> > y.
> >
> > On 10 July 2017 at 10:25, Arjen Markus <Arj...@de...> wrote:
> >> Hi Phil,
> >>
> >>
> >>
> >> That is definitely a possibility. I had another search for wxSize. At
> >> first I only found wxSizer (which is not the class I was looking
> >> for), but finally I did - in a header file "gdicmn.h":
> >>
> >>
> >>
> >> class WXDLLIMPEXP_CORE wxSize
> >>
> >> {
> >>
> >> public:
> >>
> >>     // members are public for compatibility, don't use them directly.
> >>
> >>     int x, y;
> >>
> >>
> >>
> >> I have no idea what to make of the comment ...
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Arjen
> >>
> >>
> >>
> >>
> >>
> >> From: p.d...@gm... [mailto:p.d...@gm...]
> >> Sent: Monday, July 10, 2017 10:59 AM
> >> To: Arjen Markus; Alan W. Irwin
> >>
> >>
> >> Subject: RE: The wxwidgets version you use for MSVC
> >>
> >>
> >>
> >> Hmm, I wonder if wxUSE_STRING_POS_CACHE is set during the wxWidgets
> >> build of the dlls, but then not during the build of plplot. That
> >> would explain a linker error there i think.
> >>
> >>
> >>
> >> You could search for wxSize::wxSize which should locate the
> >> constructors for that class, if they exist.
> >>
> >>
> >>
> >> Phil
> >>
> >>
> >>
> >> Sent from my Windows 10 phone
> >>
> >>
> >>
> >> From: Arjen Markus
> >> Sent: 10 July 2017 08:22
> >> To: p.d...@gm...; Alan W. Irwin
> >> Subject: RE: The wxwidgets version you use for MSVC
> >>
> >>
> >>
> >> Hi Phil,
> >>
> >>
> >>
> >> See my answers below in context.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Arjen
> >>
> >>
> >>
> >>
> >>
> >> From: p.d...@gm... [mailto:p.d...@gm...]
> >> Sent: Monday, July 10, 2017 12:24 AM
> >> To: Alan W. Irwin
> >> Cc: Arjen Markus
> >> Subject: RE: The wxwidgets version you use for MSVC
> >>
> >>
> >>
> >> Hi Arjen
> >>
> >> Have you built any other wxWidgets applications with this library version.
> >> Also is there a chance that you could be accessing headers from a
> >> version that s different to the dll?
> >>
> >>
> >>
> >>>>AM: I have not tried to build anything else. I had a "hello, world"
> >>>> example, but I compiled that under MinGW and as that worked and the
> >>>>PLplot  build failed, I do not think it is representative for the current problem.
> >>
> >>
> >>
> >> Usually when I see wxString involved my first guess s a Unicode
> >> related flag miss match. But with those two particular methods being
> >> unrelated and probably relatively small functions, I wondered if they
> >> have been swapped from inline to not inline between wx versions, and
> >> hence if you pick up a header without inlined versions but a dll with
> >> inlined versions you will get linker errors. Just a guess though.
> >>
> >> Also try using dependency walker or dumpbin (fed into grep if you
> >> have access to it) to check if those methods or some variants are
> >> really in the dll.
> >>
> >>
> >>
> >>>>AM: The libraries and header files come from the "official"
> >>>>wxWidgets  site. But they are the DLLs only, not the static ones. I
> >>>>searched for the  string "wxString" in the header files and the
> >>>>libraries (import and DLL),  but it is ubiquitous - 904 header files
> >>>>contain that string. Luckily that  was not the case for ~wxString.
> >>>>That is defined in the string.h header file,  but conditionally:
> >>
> >>
> >>
> >> #if wxUSE_STRING_POS_CACHE
> >>
> >>   ~wxString()
> >>
> >>   {
> >>
> >>       // we need to invalidate our cache entry as another string
> >> could be
> >>
> >>       // recreated at the same address (unlikely, but still possible,
> >> with the
> >>
> >>       // heap-allocated strings but perfectly common with
> >> stack-allocated
> >> ones)
> >>
> >>       InvalidateCache();
> >>
> >>   }
> >>
> >> #endif // wxUSE_STRING_POS_CACHE
> >>
> >>
> >>
> >> No such luck though with wxSize - 504 header files.
> >>
> >>
> >>
> >> I have not yet inspected the 34 DLLs ... that is for later.
> >>
> >> DISCLAIMER: This message is intended exclusively for the addressee(s)
> >> and may contain confidential and privileged information. If you are
> >> not the intended recipient please notify the sender immediately and
> >> destroy this message. Unauthorized use, disclosure or copying of this
> >> message is strictly prohibited. The foundation 'Stichting Deltares',
> >> which has its seat at Delft, The Netherlands, Commercial Registration
> >> Number 41146461, is not liable in any way whatsoever for consequences
> >> and/or damages resulting from the improper, incomplete and untimely
> >> dispatch, receipt and/or content of this e-mail.
> >>
> >>
> >>
> >> DISCLAIMER: This message is intended exclusively for the addressee(s)
> >> and may contain confidential and privileged information. If you are
> >> not the intended recipient please notify the sender immediately and
> >> destroy this message. Unauthorized use, disclosure or copying of this
> >> message is strictly prohibited. The foundation 'Stichting Deltares',
> >> which has its seat at Delft, The Netherlands, Commercial Registration
> >> Number 41146461, is not liable in any way whatsoever for consequences
> >> and/or damages resulting from the improper, incomplete and untimely
> >> dispatch, receipt and/or content of this e-mail.

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] The wxwidgets version you use for MSVC

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

I just checked in my version. I have

class WXDLLIMPEXP_CORE wxSize
{
public:
    // members are public for compatibility, don't use them directly.
    int x, y;
    // constructors
    wxSize() : x(0), y(0) { }
    wxSize(int xx, int yy) : x(xx), y(yy) { }

The last line is the important one. What does it look like in your version?

I have just looked on GitHub on the latest source
(https://github.com/wxWidgets/wxWidgets/blob/master/interface/wx/gdicmn.h)
and this constructor has indeed changed to not inlined and instead
looks like

wxSize(int width, int height);

I would suggest that there is some mismatch between the headers you
have and the dll. The dll used inlined version, so includes no
definition and the headers have the non inlined version so also
includes no definition. The linker is therefore rightfully complaining
there is no definition. If this is the case then it's a bug with the
wxWidgets distribution.

Phil

On 10 July 2017 at 10:48, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Arjen
> That looks like the class you are looking for. Those comments
> shouldn't be important. They just mean that you can access x and y
> exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
> But the comment says please don't do this.
>
> Further down in that class is there a constructor? it will look
> something like wxSize( int w, int h). It looks like a function
> declaration, but with no return type. The variable names may be
> different too - probably some variation on width and height or x and
> y.
>
> On 10 July 2017 at 10:25, Arjen Markus <Arj...@de...> wrote:
>> Hi Phil,
>>
>>
>>
>> That is definitely a possibility. I had another search for wxSize. At first
>> I only found wxSizer (which is not the class I was looking for), but finally
>> I did – in a header file “gdicmn.h”:
>>
>>
>>
>> class WXDLLIMPEXP_CORE wxSize
>>
>> {
>>
>> public:
>>
>>     // members are public for compatibility, don't use them directly.
>>
>>     int x, y;
>>
>>
>>
>> I have no idea what to make of the comment …
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>
>>
>> From: p.d...@gm... [mailto:p.d...@gm...]
>> Sent: Monday, July 10, 2017 10:59 AM
>> To: Arjen Markus; Alan W. Irwin
>>
>>
>> Subject: RE: The wxwidgets version you use for MSVC
>>
>>
>>
>> Hmm, I wonder if wxUSE_STRING_POS_CACHE is set during the wxWidgets build of
>> the dlls, but then not during the build of plplot. That would explain a
>> linker error there i think.
>>
>>
>>
>> You could search for wxSize::wxSize which should locate the constructors for
>> that class, if they exist.
>>
>>
>>
>> Phil
>>
>>
>>
>> Sent from my Windows 10 phone
>>
>>
>>
>> From: Arjen Markus
>> Sent: 10 July 2017 08:22
>> To: p.d...@gm...; Alan W. Irwin
>> Subject: RE: The wxwidgets version you use for MSVC
>>
>>
>>
>> Hi Phil,
>>
>>
>>
>> See my answers below in context.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>
>>
>>
>>
>> From: p.d...@gm... [mailto:p.d...@gm...]
>> Sent: Monday, July 10, 2017 12:24 AM
>> To: Alan W. Irwin
>> Cc: Arjen Markus
>> Subject: RE: The wxwidgets version you use for MSVC
>>
>>
>>
>> Hi Arjen
>>
>> Have you built any other wxWidgets applications with this library version.
>> Also is there a chance that you could be accessing headers from a version
>> that s different to the dll?
>>
>>
>>
>>>>AM: I have not tried to build anything else. I had a “hello, world”
>>>> example, but I compiled that under MinGW and as that worked and the PLplot
>>>> build failed, I do not think it is representative for the current problem.
>>
>>
>>
>> Usually when I see wxString involved my first guess s a Unicode related flag
>> miss match. But with those two particular methods being unrelated and
>> probably relatively small functions, I wondered if they have been swapped
>> from inline to not inline between wx versions, and hence if you pick up a
>> header without inlined versions but a dll with inlined versions you will get
>> linker errors. Just a guess though.
>>
>> Also try using dependency walker or dumpbin (fed into grep if you have
>> access to it) to check if those methods or some variants are really in the
>> dll.
>>
>>
>>
>>>>AM: The libraries and header files come from the “official” wxWidgets
>>>> site. But they are the DLLs only, not the static ones. I searched for the
>>>> string “wxString” in the header files and the libraries (import and DLL),
>>>> but it is ubiquitous – 904 header files contain that string. Luckily that
>>>> was not the case for ~wxString. That is defined in the string.h header file,
>>>> but conditionally:
>>
>>
>>
>> #if wxUSE_STRING_POS_CACHE
>>
>>   ~wxString()
>>
>>   {
>>
>>       // we need to invalidate our cache entry as another string could be
>>
>>       // recreated at the same address (unlikely, but still possible, with
>> the
>>
>>       // heap-allocated strings but perfectly common with stack-allocated
>> ones)
>>
>>       InvalidateCache();
>>
>>   }
>>
>> #endif // wxUSE_STRING_POS_CACHE
>>
>>
>>
>> No such luck though with wxSize – 504 header files.
>>
>>
>>
>> I have not yet inspected the 34 DLLs … that is for later.
>>
>> DISCLAIMER: This message is intended exclusively for the addressee(s) and
>> may contain confidential and privileged information. If you are not the
>> intended recipient please notify the sender immediately and destroy this
>> message. Unauthorized use, disclosure or copying of this message is strictly
>> prohibited. The foundation 'Stichting Deltares', which has its seat at
>> Delft, The Netherlands, Commercial Registration Number 41146461, is not
>> liable in any way whatsoever for consequences and/or damages resulting from
>> the improper, incomplete and untimely dispatch, receipt and/or content of
>> this e-mail.
>>
>>
>>
>> DISCLAIMER: This message is intended exclusively for the addressee(s) and
>> may contain confidential and privileged information. If you are not the
>> intended recipient please notify the sender immediately and destroy this
>> message. Unauthorized use, disclosure or copying of this message is strictly
>> prohibited. The foundation 'Stichting Deltares', which has its seat at
>> Delft, The Netherlands, Commercial Registration Number 41146461, is not
>> liable in any way whatsoever for consequences and/or damages resulting from
>> the improper, incomplete and untimely dispatch, receipt and/or content of
>> this e-mail.

Re: [Plplot-devel] The wxwidgets version you use for MSVC

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

Hi Phil,



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
> Sent: Monday, July 10, 2017 11:49 AM
> To: Arjen Markus; plp...@li...
> Cc: Alan W. Irwin
> Subject: Re: The wxwidgets version you use for MSVC
>
> Hi Arjen
> That looks like the class you are looking for. Those comments shouldn't be
> important. They just mean that you can access x and y exactly like in a C struct, for
> example wxSize mySize; mySize.x=4;.
> But the comment says please don't do this.
>

Right, I misread that as meaning the data AND the method members, but it only refers to the data members.

> Further down in that class is there a constructor? it will look something like
> wxSize( int w, int h). It looks like a function declaration, but with no return type. The
> variable names may be different too - probably some variation on width and height
> or x and y.
>
There are two in fact:

    // constructors

    wxSize() : x(0), y(0) { }

    wxSize(int xx, int yy) : x(xx), y(yy) { }

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] The wxwidgets version you use for MSVC

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

Hi Arjen
That looks like the class you are looking for. Those comments
shouldn't be important. They just mean that you can access x and y
exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
But the comment says please don't do this.

Further down in that class is there a constructor? it will look
something like wxSize( int w, int h). It looks like a function
declaration, but with no return type. The variable names may be
different too - probably some variation on width and height or x and
y.

On 10 July 2017 at 10:25, Arjen Markus <Arj...@de...> wrote:
> Hi Phil,
>
>
>
> That is definitely a possibility. I had another search for wxSize. At first
> I only found wxSizer (which is not the class I was looking for), but finally
> I did – in a header file “gdicmn.h”:
>
>
>
> class WXDLLIMPEXP_CORE wxSize
>
> {
>
> public:
>
>     // members are public for compatibility, don't use them directly.
>
>     int x, y;
>
>
>
> I have no idea what to make of the comment …
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> From: p.d...@gm... [mailto:p.d...@gm...]
> Sent: Monday, July 10, 2017 10:59 AM
> To: Arjen Markus; Alan W. Irwin
>
>
> Subject: RE: The wxwidgets version you use for MSVC
>
>
>
> Hmm, I wonder if wxUSE_STRING_POS_CACHE is set during the wxWidgets build of
> the dlls, but then not during the build of plplot. That would explain a
> linker error there i think.
>
>
>
> You could search for wxSize::wxSize which should locate the constructors for
> that class, if they exist.
>
>
>
> Phil
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Arjen Markus
> Sent: 10 July 2017 08:22
> To: p.d...@gm...; Alan W. Irwin
> Subject: RE: The wxwidgets version you use for MSVC
>
>
>
> Hi Phil,
>
>
>
> See my answers below in context.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> From: p.d...@gm... [mailto:p.d...@gm...]
> Sent: Monday, July 10, 2017 12:24 AM
> To: Alan W. Irwin
> Cc: Arjen Markus
> Subject: RE: The wxwidgets version you use for MSVC
>
>
>
> Hi Arjen
>
> Have you built any other wxWidgets applications with this library version.
> Also is there a chance that you could be accessing headers from a version
> that s different to the dll?
>
>
>
>>>AM: I have not tried to build anything else. I had a “hello, world”
>>> example, but I compiled that under MinGW and as that worked and the PLplot
>>> build failed, I do not think it is representative for the current problem.
>
>
>
> Usually when I see wxString involved my first guess s a Unicode related flag
> miss match. But with those two particular methods being unrelated and
> probably relatively small functions, I wondered if they have been swapped
> from inline to not inline between wx versions, and hence if you pick up a
> header without inlined versions but a dll with inlined versions you will get
> linker errors. Just a guess though.
>
> Also try using dependency walker or dumpbin (fed into grep if you have
> access to it) to check if those methods or some variants are really in the
> dll.
>
>
>
>>>AM: The libraries and header files come from the “official” wxWidgets
>>> site. But they are the DLLs only, not the static ones. I searched for the
>>> string “wxString” in the header files and the libraries (import and DLL),
>>> but it is ubiquitous – 904 header files contain that string. Luckily that
>>> was not the case for ~wxString. That is defined in the string.h header file,
>>> but conditionally:
>
>
>
> #if wxUSE_STRING_POS_CACHE
>
>   ~wxString()
>
>   {
>
>       // we need to invalidate our cache entry as another string could be
>
>       // recreated at the same address (unlikely, but still possible, with
> the
>
>       // heap-allocated strings but perfectly common with stack-allocated
> ones)
>
>       InvalidateCache();
>
>   }
>
> #endif // wxUSE_STRING_POS_CACHE
>
>
>
> No such luck though with wxSize – 504 header files.
>
>
>
> I have not yet inspected the 34 DLLs … that is for later.
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

Re: [Plplot-devel] Problems with the "new" wxwidgets device driver and example 14

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

On 2017-07-07 11:22-0700 Alan W. Irwin wrote:
[...]
> My feeling is the most likely cause of the current difficulties (both
> on Linux and Windows) is some interference between the two streams,
> i.e., this device driver is not currently stream safe.

>From further evidence it appears that feeling was wrong.  :-)

I just now did two experiments where master was wxwidgets and slave
was xwin, and vice versa, and for these conditions where only one
wxwidgets device/wxPLViewer pair was running (so stream interference
between one wxwidgets/wxPLViewer pair and another is not an issue),
there are still two distinct issues:

1.  When wxwidgets is the master and xwin the slave, xwin immediately
runs through its two pages and exits in error, i.e., it never pauses. 
This issue does not occur (xwin slave displays the first page when
master is displaying the first page, and xwin display the second page
when master is displaying the second page) if xwin is both master and
slave or if xcairo or qtwidget is master and xwin the slave.  (The
qtwidget/xwin combination segfaults at the exit from the example, but
that must be a completely different issue.) This nopause issue for the
slave implies that wxwidgets as master is not doing a complete job of
handling pauses. (I don't fully understand the x14c code, but it
appears pausing is turned off for the slave in the expectation that
the master will take care of overall pausing.  That overall pausing
control does occur when other devices are master, but not when
wxwidgets is master.)

2. When other devices are master and wxwidgets the slave, the slave
displays as a blank box.

The combination of 1. and 2. is exactly what you see when wxwidgets is
both master and slave (the usual case for example 14 when you specify
-dev wxwidgets).  That is, the disappearing slave GUI you get in that
case can be completely explained by the combination of the above two
issues.

I would welcome a fix for either/both these two issues before the
release, but I don't think we should delay the release for these two
fixes.

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] Problems with the "new" wxwidgets device driver and example 14

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

On 2017-07-07 09:57+0100 p.d...@gm... wrote:

[...]
> I believe that yes multiple streams did used to work with wxWidgets.

Hi Phil:

It was good to hear from you.

Your comment inspired me to try running

examples/c/x14c -dev wxwidgets

on my Linux platform for 5.11.0 (the release where the new wxwidgets device driver was
first introduced), 5.11.1, and 5.12.0.  There was a fresh
configuration and build for each version.

5.11.0 displayed both master and slave GUI, but they were independent of each
other, i.e., moving forward one page on one left the other completely unaffected.

5.11.1 segfaulted (oops, we should have caught that before that
release!).

5.12.0 (before any of my IPC changes were introduced) has the present
bad behaviour, i.e., slave GUI appears momentarily and then disappears.

In sum, the behaviour of the new -dev wxwidgets has never been correct
and has sometimes been completely problematic on Linux for example 14.
So from this troubled Linux history I am not surprised that Arjen has also
discovered a serious hang issue for this example on Windows.

My feeling is the most likely cause of the current difficulties (both
on Linux and Windows) is some interference between the two streams,
i.e., this device driver is not currently stream safe.  I am curious
enough about that possibility to take a quick look, but I have other
pre-release issues on my plate so if I cannot discover a quick fix
(and nobody else can either), then we will have to put off looking at
this until after the current 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: Wednesday, July 05, 2017 8:38 PM
> @Arjen:
>
> Glad you solved the find issue.  Please commit your fix to
> cmake/modules/FindwxWidgets.cmake
>

Will do - I will have to clean up the file a bit though - sundry debug output statements added ;).

> I did a google search for the terms <msvc wxwidgets unresolved external symbol
> __declspec(dllimport) public: __cdecl wxSize::wxSize(int,int)> (related to the second
> linking error message above) and found
> <https://stackoverflow.com/questions/42036606/wxwidgets-visual-studio-2015-link-
> errors>
> where it indicates that such linking errors generally occur if the preprocessor macro
> WXUSINGDLL is not #defined when shared libraries are used.
>
> Apparently cmake/modules/FindwxWidgets.cmake does set this macro in certain
> circumstances, but I wonder if those have actually occurred in your case.  To find
> out, please look at your cmake output.  Does the line
>
> -- wxWidgets_DEFINITIONS  <list of definitions>
>
> include WXUSINGDLL in the list?
>

It does:

-- wxWidgets_FOUND             : TRUE

-- wxWidgets_INCLUDE_DIRS      : D:/wxwidgets/lib/vc120_dll/mswu;D:/wxwidgets/include

-- wxWidgets_LIBRARIES         : debug;D:/wxwidgets/lib/vc120_dll/wxbase30ud.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxbase30u.lib;debug;D:/wxwidgets/lib/vc120_dll/wxmsw30ud_core.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxmsw30u_core.lib;debug;D:/wxwidgets/lib/vc120_dll/wxpngd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxpng.lib;debug;D:/wxwidgets/lib/vc120_dll/wxtiffd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxtiff.lib;debug;D:/wxwidgets/lib/vc120_dll/wxjpegd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxjpeg.lib;debug;D:/wxwidgets/lib/vc120_dll/wxzlibd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxzlib.lib;debug;D:/wxwidgets/lib/vc120_dll/wxregexud.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxregexu.lib;debug;D:/wxwidgets/lib/vc120_dll/wxexpatd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32

-- wxWidgets_LIBRARY_DIRS      :

-- wxWidgets_DEFINITIONS       : WXUSINGDLL;UNICODE;_UNICODE;UNICODE;_UNICODE

-- wxWidgets_DEFINITIONS_DEBUG : _DEBUG;__WXDEBUG__

-- Checking whether wxwidgets version >= 3.0.0

-- Performing Test WX_VERSION_LARGE_ENOUGH

-- Performing Test WX_VERSION_LARGE_ENOUGH - Success

An excerpt from the output of CMake, but it is the _only_ file that contains the wxwidgets_DEFINITIONS macro.

> Assuming so, does "nmake VERBOSE=1" confirm that -DWXUSINGDLL is being
> used in your compilations of wxwidgets-related code?
>
The flag is used, I can see that in the generated files that together comprise the makefile, but unfortunately the nmake output (even verbose) merely shows that all manner of flags are incorporated in temporary files.

> I expect you will find no problems with WXUSINGDLL (since you had visibility
> issues with just a few symbols and not all of them), but you should double-check as
> above simply as part of your "due diligence".  But ultimately the answer may be to
> use a different wxwidgets installation, see my question to Phil and Pedro above.
>
I cannot be 100% certain, but the flag occurs plainly in the various files, no extra conditions. So the answer will probably lie in the use of a different installation.

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] Problems with the "new" wxwidgets device driver and example 14

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

To Arjen, Phil, and Pedro:

Note new subject line:

@Phil and Pedro:

Have you guys ever tested example 14 with -dev wxwidgets on Windows?
That's an important question since your answers might help us to figure
out if this example 14 wxwidgets issue is a long-standing one for the
"new" version of this device or some recently introduced regression.

On 2017-07-05 12:21-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, July 04, 2017 12:30 AM
>>
>> 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.
>
>
> I ran this last night and it was almost completely successful. However, example x14c will not stop - I had to kill it manually and that, of course, upsets the test script. I tried this example standalone: it brings up two windows, when you click in them, they disappear but ultimately the program itself remains active.
>
> We are therefore not quite there yet. I had not turned on the debugging output, so I cannot share an extra output file.

@Arjen:

The short story is please try the comprehensive test again with the
latest version (commit b05d501) which is not a fix for this issue but
instead simply ignores example 14 for comprehensive testing of
wxwidgets.  I cannot replicate this hang on Linux, but there
are enough problems there, that I think we should fix those (likely
post-release) before worrying about example 14 for wxwidgets on
Windows (in case there is one bug that manifests itself as an early
exit for the slave GUI on Linux and as a hang on Windows).

The longer story is I further investigated the Linux case by doing the
following test for three different fresh configurations:

# Build prerequisites:
(make VERBOSE=1 wxwidgets; make VERBOSE=1 wxPLViewer; make VERBOSE=1 x14c) >& build.out

# Normal run
examples/c/x14c -dev wxwidgets

# -np run (that option is also used in comprehensive tests).
examples/c/x14c -dev wxwidgets -np

The different configurations and the corresponding results are as
follows:

1.  Default configuration (what you used above corresponding to
     -DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON).  This is
     the 3 semaphores approach for the IPC required for the
     "new" wxwidgets device driver.

For the normal run, the first page of the master GUI appeared and the
first page of the slave GUI appeared (which had the same size box as
the master GUI).  However, that page of the slave GUI immediately
disappeared again (which is a bug). Hitting the enter key on the
master GUI advanced to the second page of the master GUI (with no
corresponding slave GUI at all).  Hitting the enter key again for the
second page of the master GUI exited normally. There were no hangs,
leftover jobs running in the background, or leftover files in /dev/shm
(where the shared memory and named semaphores "files" appear on
Linux).

For the -np run, two empty boxes appeared and then disappeared
(consistent with the first results since the -np option is supposed to
remove the necessity for hitting the enter key to move between pages
and exit the GUI.  The empty pages were the result of the
long-standing -np bug for wxwidgets where only empty boxes are
displayed). There were no hangs, leftover jobs running in the
background, or leftover files in /dev/shm (where the shared memory and
named semaphores "files" appear on Linux).

2. Specified -DPL_WXWIDGETS_IPC3=OFF (for default -DOLD_WXWIDGETS=OFF).
This is the mutex (Windows) or one-semaphore approach (Linux) using a circular
buffer and timed wait loops for the IPC for the "new" wxwidgets device
driver.

All these results were identical to those in 1. above except that the
slave GUI box was 3/4ths the size of the master GUI box (presumably
due to some minor issue with this approach, but I am not going to
worry about that issue since I believe the PL_WXWIDGETS_IPC3 variant
of the IPC method is what we should be developing moving forward).

3. -DOLD_WXWIDGETS=ON.
This is the old version of the wxwidgets device driver that does not use IPC at all
and which is only minimally maintained.

Example 14 shows no bugs for this old version of device driver
compared to the two bugs found above for the new version of this
device driver.  For the normal run both the master and slave GUIs
appear (and both stay displayed) and hitting the enter key on either
of them advances both to the next page (when they are both on their
respective first pages) or exits both (when they are both on their
respective second pages). For the -np run, both the master and slave
GUIs appear and actually show plotted results (as opposed to the empty
GUI boxes that appear for the new version of this device above).  Like
the new version of this device driver, there were no hangs and no
leftover jobs running in the background.

For both types of runs there were the following set of warnings:

../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC(): Wrong GC
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC(): Wrong GC
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC(): Wrong GC
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC(): Wrong GC

These warnings appear to be due to some wxwidgets-3.x constraint that
our old version of the device driver (which was developed for
wxwidgets-2) is violating, and therefore, these warning are likely the
result of our decision to do only minimal maintenance for the old
version of this device driver.

My conclusion from the sobering results of these tests is there is
still lots of work we need to do to bring the new version of this
device driver up to the standards of the old version even just for
this one example on the Linux platform.  (The bug with regard to the
slave GUI disappearing is only demonstrated by this example, but the
empty box bug for the -np option is shown by all examples.) And from
your experience there is even a worse issue (a hang) for this example
on Windows. So I have decided (commit b05d501) to temporarily ignore
example 14 for our tests of -dev wxwidgets for all platforms, and this
change should likely allow you to complete the comprehensive testing
of wxwidgets on MinGW-w64/MSYS2.  But please check that by repeating
the comprehensive test on that platform!

My further general conclusion is we still want to deal with these
issues of the new version rather than simply abandoning it and using
the old version instead. The reason for that conclusion is the
complexity of the old version (actually 3 kinds of wxwidgets devices)
made it extremely difficult to maintain or understand, and if I recall
correctly what Phil said about his new design, the IPC used in the new
version to send data between -dev wxwidgets and the new independent
viewer, wxPLViewer, makes it possible to isolate the known
thread-safety issues of PLplot from the thread-safe wxwidgets
environment while that lack of isolation was an important issue for
the old wxwidgets approach.

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...>]

To Phil, Pedro, and Arjen:

@Phil and Pedro:
You guys are the ones with experience
with MSVC and wxwidgets here.  So are you willing to help
Arjen with the linking problem below?  Or recommend
the version of wxwidgets that works for you in combination
with MSVC?

@Arjen:

Glad you solved the find issue.  Please commit your fix
to cmake/modules/FindwxWidgets.cmake

Below I suggest a few things to check concerning the msvc/wxwidgets
linking problem you have encountered.

On 2017-07-05 12:28-0000 Arjen Markus wrote:

>
> However, the make step failed:
>
>            cd D:\plplot-svn\build-windows-alt
>
> [ 20%] Linking CXX shared library ..\..\dll\plplotwxwidgets.dll
>
>            cd D:\plplot-svn\build-windows-alt\bindings\wxwidgets
>
>            D:\cmake3.8.0\bin\cmake.exe -E vs_link_dll --intdir=CMakeFiles\plplotwxwidgets.dir --manifests  -- C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\plplotwxwidgets.dir\objects1.rsp @C:\Users\markus\AppData\Local\Temp\nm4431.tmp
>
> Visual Studio Incremental Link with embedded manifests
>
> Create CMakeFiles\plplotwxwidgets.dir/manifest.rc
>
> RC Pass 1:
>
> C:/Program Files (x86)/Windows Kits/8.1/bin/x64/rc.exe /foCMakeFiles\plplotwxwidgets.dir/manifest.res CMakeFiles\plplotwxwidgets.dir/manifest.rc
>
> LINK Pass 1:
>
> C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\plplotwxwidgets.dir\objects1.rsp /out:..\..\dll\plplotwxwidgets.dll /implib:..\..\dll\plplotwxwidgets.lib /pdb:D:\plplot-svn\build-windows-alt\dll\plplotwxwidgets.pdb /dll /version:1.2 /machine:x64 /debug /INCREMENTAL ..\..\dll\plplotcxx.lib D:\wxwidgets\lib\vc120_dll\wxbase30ud.lib D:\wxwidgets\lib\vc120_dll\wxmsw30ud_core.lib D:\wxwidgets\lib\vc120_dll\wxpngd.lib D:\wxwidgets\lib\vc120_dll\wxtiffd.lib D:\wxwidgets\lib\vc120_dll\wxjpegd.lib D:\wxwidgets\lib\vc120_dll\wxzlibd.lib D:\wxwidgets\lib\vc120_dll\wxregexud.lib D:\wxwidgets\lib\vc120_dll\wxexpatd.lib winmm.lib comctl32.lib oleacc.lib rpcrt4.lib shlwapi.lib version.lib wsock32.lib ..\..\dll\plplot.lib ..\..\dll\csirocsa.lib ..\..\dll\qsastime.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\plplotwxwidgets.dir/intermediate.manifest CMakeFiles\plplotwxwidgets.dir/manifest.res
>
>   Creating library ..\..\dll\plplotwxwidgets.lib and object ..\..\dll\plplotwxwidgets.exp
>
> wxPLplotstream.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl wxString::~wxString(void)" (__imp_??1wxString@@QEAA@XZ) referenced in function "public: void * __cdecl wxString::`vector deleting destructor'(unsigned int)" (??_EwxString@@QEAAPEAXI@Z)
>
> wxPLplotstream.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl wxSize::wxSize(int,int)" (__imp_??0wxSize@@QEAA@HH@Z) referenced in function "public: void __cdecl wxPLplotstream::SetSize(int,int)" (?SetSize@wxPLplotstream@@QEAAXHH@Z)
>
> ..\..\dll\plplotwxwidgets.dll : fatal error LNK1120: 2 unresolved externals
>
> LINK Pass 1 failed. with 1120
>
> NMAKE : fatal error U1077: 'D:\cmake3.8.0\bin\cmake.exe' : return code '0xffffffff'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> As far as I can tell, all the wxWidgets libraries are present, but I admit I did not make a thorough investigation into this.

I did a google search for the terms <msvc wxwidgets unresolved
external symbol __declspec(dllimport) public: __cdecl
wxSize::wxSize(int,int)> (related to the second linking error message above)
and found
<https://stackoverflow.com/questions/42036606/wxwidgets-visual-studio-2015-link-errors>
where it indicates that such linking errors generally occur if the preprocessor macro WXUSINGDLL
is not #defined when shared libraries are used.

Apparently cmake/modules/FindwxWidgets.cmake does set this macro in
certain circumstances, but I wonder if those have actually occurred
in your case.  To find out, please look at your cmake output.  Does
the line

-- wxWidgets_DEFINITIONS  <list of definitions>

include WXUSINGDLL in the list?

Assuming so, does "nmake VERBOSE=1" confirm that
-DWXUSINGDLL is being used in your compilations of wxwidgets-related
code?

I expect you will find no problems with WXUSINGDLL (since you had
visibility issues with just a few symbols and not all of them), but you should
double-check as above simply as part of your "due diligence".  But
ultimately the answer may be to use a different wxwidgets
installation, see my question to Phil and Pedro above.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] 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 11:08 PM
>
> I would advise concentrating on debugging the results of each relevant find
> command (e.g., find_library, find_path, find_file, and possibly
> find_program) within that code since there are relatively few such commands within
> that find module logic, and it is pretty likely that find module is failing to find your
> installation because one or more of those find commands is failing.
>
I have found the omission that caused wxWidgets not to be recognised. The libraries are stored in d:\wxWidgets\lib\vc120_dll and that was not a pattern that was checked (the existing patterns all have the architecture - 32 or 64 bits - included). So when I added a pattern consistent with the directory from my installation, CMake recognised the wxWidgets installation (no extra parameters required).

However, the make step failed:

            cd D:\plplot-svn\build-windows-alt

[ 20%] Linking CXX shared library ..\..\dll\plplotwxwidgets.dll

            cd D:\plplot-svn\build-windows-alt\bindings\wxwidgets

            D:\cmake3.8.0\bin\cmake.exe -E vs_link_dll --intdir=CMakeFiles\plplotwxwidgets.dir --manifests  -- C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\plplotwxwidgets.dir\objects1.rsp @C:\Users\markus\AppData\Local\Temp\nm4431.tmp

Visual Studio Incremental Link with embedded manifests

Create CMakeFiles\plplotwxwidgets.dir/manifest.rc

RC Pass 1:

C:/Program Files (x86)/Windows Kits/8.1/bin/x64/rc.exe /foCMakeFiles\plplotwxwidgets.dir/manifest.res CMakeFiles\plplotwxwidgets.dir/manifest.rc

LINK Pass 1:

C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\link.exe /nologo @CMakeFiles\plplotwxwidgets.dir\objects1.rsp /out:..\..\dll\plplotwxwidgets.dll /implib:..\..\dll\plplotwxwidgets.lib /pdb:D:\plplot-svn\build-windows-alt\dll\plplotwxwidgets.pdb /dll /version:1.2 /machine:x64 /debug /INCREMENTAL ..\..\dll\plplotcxx.lib D:\wxwidgets\lib\vc120_dll\wxbase30ud.lib D:\wxwidgets\lib\vc120_dll\wxmsw30ud_core.lib D:\wxwidgets\lib\vc120_dll\wxpngd.lib D:\wxwidgets\lib\vc120_dll\wxtiffd.lib D:\wxwidgets\lib\vc120_dll\wxjpegd.lib D:\wxwidgets\lib\vc120_dll\wxzlibd.lib D:\wxwidgets\lib\vc120_dll\wxregexud.lib D:\wxwidgets\lib\vc120_dll\wxexpatd.lib winmm.lib comctl32.lib oleacc.lib rpcrt4.lib shlwapi.lib version.lib wsock32.lib ..\..\dll\plplot.lib ..\..\dll\csirocsa.lib ..\..\dll\qsastime.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\plplotwxwidgets.dir/intermediate.manifest CMakeFiles\plplotwxwidgets.dir/manifest.res

   Creating library ..\..\dll\plplotwxwidgets.lib and object ..\..\dll\plplotwxwidgets.exp

wxPLplotstream.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl wxString::~wxString(void)" (__imp_??1wxString@@QEAA@XZ) referenced in function "public: void * __cdecl wxString::`vector deleting destructor'(unsigned int)" (??_EwxString@@QEAAPEAXI@Z)

wxPLplotstream.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl wxSize::wxSize(int,int)" (__imp_??0wxSize@@QEAA@HH@Z) referenced in function "public: void __cdecl wxPLplotstream::SetSize(int,int)" (?SetSize@wxPLplotstream@@QEAAXHH@Z)

..\..\dll\plplotwxwidgets.dll : fatal error LNK1120: 2 unresolved externals

LINK Pass 1 failed. with 1120

NMAKE : fatal error U1077: 'D:\cmake3.8.0\bin\cmake.exe' : return code '0xffffffff'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

As far as I can tell, all the wxWidgets libraries are present, but I admit I did not make a thorough investigation into 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

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, July 04, 2017 12:30 AM
>
> 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.


I ran this last night and it was almost completely successful. However, example x14c will not stop - I had to kill it manually and that, of course, upsets the test script. I tried this example standalone: it brings up two windows, when you click in them, they disappear but ultimately the program itself remains active.

We are therefore not quite there yet. I had not turned on the debugging output, so I cannot share an extra output file.

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-04 07:03-0000 Arjen Markus wrote:

[...]
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, July 04, 2017 12:30 AM
[...]
>> 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!)

I would advise concentrating on debugging the results of each relevant
find command (e.g., find_library, find_path, find_file, and possibly
find_program) within that code since there are relatively few such
commands within that find module logic, and it is pretty likely that
find module is failing to find your installation because
one or more of those find commands is failing.

>From the documentation of wxWidgets_ROOT_DIR and wxWidgets_LIB_DIR it
appears to me those variables are meant to select a particular version
of wxwidgets when there are multiple choices, and there must be 
assumptions about the layout of your wxwidgets installation underneath
those very broad prefixes that may not be correct for your particular
installation.

Thus, I think you should be looking at generic methods for helping
CMake to find installations such as setting CMAKE_INCLUDE_PATH and
CMAKE_LIBRARY_PATH (either as environment variables or CMake
variables, see
<https://cmake.org/cmake/help/latest/command/find_library.html>,
<https://cmake.org/cmake/help/latest/command/find_path.html>, etc.,
for each kind of find command that you are debugging.) Finally, I
would advise looking carefully at the last subdirectory of the prefix
information you are supplying with CMAKE_INCLUDE_PATH and
CMAKE_LIBRARY_PATH. That is, if the code is attempting to find, e.g.,
include/wx/wx.h, and you have supplied a directory prefix whose last
subdirectory is .../include or .../include/wx, then that find will fail.

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
__________________________