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.rosenb...@gmail.com> 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 <arjen.mar...@deltares.nl> 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.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
>> 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.rosenb...@gmail.com; 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.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
>> 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.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
