Re: [Plplot-devel] plplot_pyqt4 shared object build issue
Hi Alan,
> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Sunday, December 11, 2016 11:25 PM
>
> Unfortunately, those compiler warnings in the report about "redeclared without
> dllimport attribute" (and eventual build failure for the qt device driver)
> don't make a
> lot of sense to me at the present time.
That is only a warning, the errors that the compiler finds are related to:
const QMetaObjectExtraData MasterHandler::staticMetaObjectExtraData = {
The odd thing is that the file moc_qt.cpp contains multiple definitions of this
member as well as the function qt_static_metacall. I cannot find a version
where the dllimport attribute is used.
I compared the code to the one generated by the regular build (the august one)
and they are identical apart from the file extension (.cpp versus .cxx) and the
timestamp.
This is really puzzling, I agree with your analysis that there should be no
difference between the two build methods.
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.
/
** Meta object code from reading C++ file 'qt.h'
**
** Created by: The Qt Meta Object Compiler version 63 (Qt 4.8.7)
**
** WARNING! All changes made in this file will be lost!
*/
#include "../../../../../plplot-git/include/qt.h"
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'qt.h' doesn't include ."
#elif Q_MOC_OUTPUT_REVISION != 63
#error "This file was generated using the moc from 4.8.7. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif
QT_BEGIN_MOC_NAMESPACE
static const uint qt_meta_data_MasterHandler[] = {
// content:
6, // revision
0, // classname
0,0, // classinfo
2, 14, // methods
0,0, // properties
0,0, // enums/sets
0,0, // constructors
0, // flags
2, // signalCount
// signals: signature, parameters, type, tag, flags
15, 14, 14, 14, 0x05,
35, 14, 14, 14, 0x05,
0// eod
};
static const char qt_meta_stringdata_MasterHandler[] = {
"MasterHandler\0\0MasterChangedPage()\0"
"MasterClosed()\0"
};
void MasterHandler::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int
_id, void **_a)
{
if (_c == QMetaObject::InvokeMetaMethod) {
Q_ASSERT(staticMetaObject.cast(_o));
MasterHandler *_t = static_cast(_o);
switch (_id) {
case 0: _t->MasterChangedPage(); break;
case 1: _t->MasterClosed(); break;
default: ;
}
}
Q_UNUSED(_a);
}
const QMetaObjectExtraData MasterHandler::staticMetaObjectExtraData = {
0, qt_static_metacall
};
const QMetaObject MasterHandler::staticMetaObject = {
{ &QObject::staticMetaObject, qt_meta_stringdata_MasterHandler,
qt_meta_data_MasterHandler, &staticMetaObjectExtraData }
};
#ifdef Q_NO_DATA_RELOCATION
const QMetaObject &MasterHandler::getStaticMetaObject() { return
staticMetaObject; }
#endif //Q_NO_DATA_RELOCATION
const QMetaObject *MasterHandler::metaObject() const
{
return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject :
&staticMetaObject;
}
void *MasterHandler::qt_metacast(const char *_clname)
{
if (!_clname) return 0;
if (!strcmp(_clname, qt_meta_stringdata_MasterHandler))
return static_cast(const_cast< MasterHandler*>(this));
return QObject::qt_metacast(_clname);
}
int MasterHandler::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
_id = QObject::qt_metacall(_c, _id, _a);
if (_id < 0)
return _id;
if (_c == QMetaObject::InvokeMetaMethod) {
if (_id < 2)
qt_static_metacall(this, _c, _id, _a);
_id -= 2;
}
return _id;
}
// SIGNAL 0
void MasterHandler::MasterChangedPage()
{
QMetaObject::activate(this, &staticMetaObject, 0, 0);
}
// SIGNAL 1
void MasterHandler::MasterClosed()
{
QMetaObject::activate(this, &staticMetaObject, 1, 0);
}
static const uint qt_meta_data_QtPLWidget[] = {
// content:
6, // revision
0, // classname
0,0, // classinfo
6, 14, // methods
0,0, // properties
0,0, // enums/sets
0,0, // constructors
0
Re: [Plplot-devel] plplot_pyqt4 shared object build issue
On 2016-12-12 08:30- Arjen Markus wrote:
> Hi Alan,
>
>
>
>> -Original Message-
>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>> Sent: Sunday, December 11, 2016 11:25 PM
>>
>> Unfortunately, those compiler warnings in the report about "redeclared
>> without
>> dllimport attribute" (and eventual build failure for the qt device driver)
>> don't make a
>> lot of sense to me at the present time.
>
> That is only a warning, the errors that the compiler finds are related to:
>
> const QMetaObjectExtraData MasterHandler::staticMetaObjectExtraData = {
>
> The odd thing is that the file moc_qt.cpp contains multiple definitions of
> this member as well as the function qt_static_metacall. I cannot find a
> version where the dllimport attribute is used.
>
> I compared the code to the one generated by the regular build (the august
> one) and they are identical apart from the file extension (.cpp versus .cxx)
> and the timestamp.
>
> This is really puzzling, I agree with your analysis that there should be no
> difference between the two build methods.
Hi Arjen:
The short story is I am looking forward to your next report.
Here is the longer story.
Thanks for those two files. It turns out the key one (qt_moc.cpp) is
essentially identical with what moc generates here, i.e.,
software@raven> diff ~irwin/Arjen.Markus/20161212/cygwin/moc_qt.cpp
qt_automoc.dir/moc_qt_2CLBWPDUEWV5LU.cpp
4c4
< ** Created by: The Qt Meta Object Compiler version 63 (Qt 4.8.7)
---
> ** Created by: The Qt Meta Object Compiler version 63 (Qt 4.8.6)
9c9
< #include "../../../../../plplot-git/include/qt.h"
---
> #include "../../../plplot.git/include/qt.h"
13c13
< #error "This file was generated using the moc from 4.8.7. It"
---
> #error "This file was generated using the moc from 4.8.6. It"
And we are agreed there is no difference between the qt.cpp build and
qt_automoc.cpp build either here or there except that
on Linux platforms, we have
#define PLDLLIMPORT
while on Cygwin platforms we have
#define PLDLLIMPORT__declspec( dllimport )
So my best guess is that on Linux (since PLDLLIMPORT is #defined to
nothing) we are getting away with something that Cygwin won't allow
where PLDLLIMPORT is something other than nothing.
In fact, further analysis shows we have qt.so linking with
libplplotqt. So libplplotqt (now that the visibility issues with it
have been solved) should be supplying all the moc-related symbols that
are needed by qt.so. Therefore, it is overkill to do moc generation
for the qt.so case, i.e., it is the same Linux workaround scenario
that I removed for the pyqt4.so case once I got libplplotqt exporting
the moc-related symbols correctly!
Therefore, to deal with this overkill workaround, I have removed
(commit 35833c7) automoc generation for the qt shared object as well
(just like I did previously for pyqt4). And just as in the pyqt4
case, that removal works well on Linux. So I have my fingers crossed
that this new slimmed down way to build the qt and pyqt4 shared
objects will work fine on Cygwin, and I look forward to your next
report that either confirms that or not. But I am strongly hoping for
confirmation because otherwise I am completely out of ideas!
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
__
--
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
Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10
Hmm And the fact that the wx libraries that were found have the suffix u, suggests they were built with Unicode support. Perhaps the compile issue you had was because plplot was not built with the Unicode flag on. As I said instructions are on the wiki to do this for a visual studio build at https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/, but I don't know how one would do it in MSYS. Perhaps setting the same flags would do it. Phil On 11 December 2016 at 10:23, Alan W. Irwin wrote: > On 2016-12-10 01:11- Phil Rosenberg wrote: > >> I'm sorry Laurent, but I think I am the main Windows user on the list >> and I have absolutely no experience with MSys. >> >> However, I believe we have now returned to the CMake default wxWidgets >> find module. Alan, can you comment on this and whether this looks like >> a bug in that module or a bug in our build system? > > > @ Phil and Laurent: > > Yes, we are using the absolutely latest official CMake wxWidgets find > module that is heavily maintained by the CMake developers. So I doubt > there are any obvious bugs in that find module. > > @Laurent: > > My apologies for not answering sooner but I was otherwise occupied with > other issues currently being discussed on the PLplot devel list. > > The short explanation of the message you were getting is that our build > system gets a list of libraries from the official find module. Some of > those are actual locations, and some are in the -L...-l... form. So we > transform the latter to actual location by looking for the library > using the find_library command, and for some reason some of those > could not be found. The cure for this is to identify the libraries > that were not found from comparing the old and transformed lists, then > installing the relevant libraries or adjust environment variables > such as PATH and/or CMAKE_LIBRARY_PATH to help CMake find the > relevant libraries. > > I must say, however, that the comparison of the two lists given to you > is a far less than optimal way to find what libraries could not be > found so I plan in the next few days to update that part of our build > system to make this WARNING message a lot clearer. > > For now, though, you are stuck with correlating the following two > lists (i.e., search for a NOTFOUND result on the second list and find > from its position what -l form it corresponded to in the orignal list) > to find what libraries are missing. > >>> cmake_link_flags WARNING: (original link flags) = >>> >>> -L/f/lib/wxWidgets-3.1.0/lib;;;-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32 >>> >>> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS = >>> >>> -Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;F:/mingw-w64/Strawberry/c/lib/libz.a;C:/Windows/System32/rpcrt4.dll;C:/Windows/System32/oleaut32.dll;C:/Windows/System32/ole32.dll;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;C:/Windows/System32/winmm.dll;C:/Windows/System32/shell32.dll;C:/Windows/System32/shlwapi.dll;C:/Windows/System32/comctl32.dll;C:/Windows/System32/comdlg32.dll;C:/Windows/System32/advapi32.dll;C:/Windows/System32/version.dll;C:/Windows/System32/wsock32.dll;C:/Windows/System32/gdi32.dll > > > To make the explanation simpler, let me break down both lists at the > semicolons: > > That means original = > > > -L/f/lib/wxWidgets-3.1.0/lib; > ; > ; > -Wl,--subsystem,windows; > -mwindows; > /f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a; > /f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a; > -lwxregexu-3.1; > -lwxexpat-3.1; > -lwxtiff-3.1; > -lwxjpeg-3.1; > -lwxpng-3.1; > -lz; > -lrpcrt4; > -loleaut32; > -lole32; > -luuid; > -lwinspool; > -lwinmm; > -lshell32; > -lshlwapi; > -lcomctl32; > -lcomdlg32; > -ladvapi32; > -lversion; > -lwsock32; > -lgdi32 > > Transformed = -Wl,--subsystem,windows; > -mwindows; > /f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a; > /f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a; > _library_pathname-NOTFOUND; > _library_pathname-NOTFOUND; > _library_pathname-NOTFOUND; > _library_pathname-NOTFOUND; > _library_pathname-NOTFOUND; > F:/mingw-w64/Strawberry/c/lib/libz.a; > C:/Windows/System32/rpcrt4.dll; > C:/Windows/System32/oleaut32.dll; > C:/Windows/System32/ole32.dll; > _library_pathname-NOTFOUND; > _library_pathname-NOTFOUND; > C:/Windows/System32/winmm.dll; > C:/Windows/System32/shell32.dll; > C:/Windows/System32/shlwapi.dll; > C:/Windows/System32/comctl32.dll; > C:/Windows/System32/comdlg32.dll; > C:/Windows/System32/advapi32.dll; > C:/Windows/System32/
Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10
I recognize one aspect of your problems in that winundef.h is imperfectly
written and will fail in the case
of using the unicode wxwidgets without explicitly already being unicode
through-and-through - which is what winundef tries to do. Attached is a
fixed version of that file from wx-3.0/wx/msw/ - I haven't gone to 3.1 yet,
it is probably the same for that.
Greg
On Sat, Dec 10, 2016 at 6:58 AM, Laurent Berger <
laurent.ber...@univ-lemans.fr> wrote:
> Hi phil,
>
> Thanks for your answer.
>
> I have try to solve problem in a bad way :
>
> I have changed some lines in pkg-config.cmake : line298--305 are now :
>
>if(_list_element STREQUAL "-l${_list_element1}")
> set(_library_pathname "_library_pathname-NOTFOUND")
> find_library(
> _library_pathname
> ${_list_element1}
> PATHS ${_link_directory_list} "f:/lib/wxWidgets-3.1.0/lib"
> "F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/
> x86_64-w64-mingw32/lib32"
> NO_DEFAULT_PATH
> )
>
>
> I can start build plplot using MSYS-mingw64. Now I have some compilation
> errors and try to understand it
>
> $ make
> [ 3%] Built target csirocsa
> [ 6%] Built target deltaT-gen
> [ 7%] Built target deltaT.h_built
> [ 9%] Built target tai-utc-gen
> [ 10%] Built target tai-utc.h_built
> [ 15%] Built target qsastime
> [ 16%] Built target plhershey-unicode-gen
> [ 18%] Built target plhershey-unicode.h_built
> [ 19%] Building CXX object
> src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj
> In file included from
> F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/
> x86_64-w64-mingw32/include/Windows.h:72:0,
> from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
> from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
> CreateDialog(HINSTANCE, LPCTSTR, HWND, DLGPROC)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:38:20: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HWND__* CreateDialogParamW(HINSTANCE, LPCWSTR,
> HWND, DLGPROC, LPARAM)'
> return CreateDialogW(hInstance, pTemplate, hwndParent,
> pDlgProc);
> ^
> In file included from F:/lib/wxWidgets-3.1.0/include/wx/defs.h:3302:0,
> from F:/lib/wxWidgets-3.1.0/include/wx/font.h:18,
> from G:/Lib/plplot/drivers/wxwidgets_comms.h:34,
> from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HFONT__*
> CreateFont(int, int, int, int, int, DWORD, DWORD, DWORD, DWORD, DWORD,
> DWORD, DWORD, DWORD, LPCTSTR)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:69:48: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '14' to 'HFONT__* CreateFontW(int, int, int, int, int,
> DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, LPCWSTR)'
> family, facename);
> ^
> In file included from
> F:/mingw-w64/x86_64-6.2.0-posix-sjlj-rt_v5-rev1/mingw64/
> x86_64-w64-mingw32/include/Windows.h:72:0,
> from G:/Lib/plplot/drivers/wxwidgets_comms.h:25,
> from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
> CreateWindow(LPCTSTR, LPCTSTR, DWORD, int, int, int, int, HWND, HMENU,
> HINSTANCE, LPVOID)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:94:20: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HWND__* CreateWindowExW(DWORD, LPCWSTR, LPCWSTR,
> DWORD, int, int, int, int, HWND, HMENU, HINSTANCE, LPVOID)'
> return CreateWindowW(lpClassName, lpWndClass, dwStyle, x,
> y, w, h,
> ^
> In file included from F:/lib/wxWidgets-3.1.0/include/wx/defs.h:3302:0,
> from F:/lib/wxWidgets-3.1.0/include/wx/font.h:18,
> from G:/Lib/plplot/drivers/wxwidgets_comms.h:34,
> from G:/Lib/plplot/drivers/wxwidgets_comms.cpp:20:
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HMENU__*
> LoadMenu(HINSTANCE, LPCTSTR)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:111:44: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HMENU__* LoadMenuW(HINSTANCE, LPCWSTR)'
> return LoadMenuW(instance, name);
> ^
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HWND__*
> FindText(LPFINDREPLACE)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:126:43: error: cannot
> convert 'LPFINDREPLACE {aka tagFINDREPLACEA*}' to 'LPFINDREPLACEW {aka
> tagFINDREPLACEW*}' for argument '1' to 'HWND__* FindTextW(LPFINDREPLACEW)'
>
Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with workaround
Hi Phil
Here's the fix I did for the linux wxwidgets driver bug
https://github.com/pedro-vicente/plplot-wxwidgets
these are the comments I added in the code
// Modified from PLplot Copyright (C) 2015 Phil Rosenberg
// Changes:
// A non templated class derived from wxFrame
// Use of events by wxDECLARE_EVENT_TABLE()
// Explicit call to CreatePLplotstream() after Create()
//wx_PLplotFrame_stream *frame = new wx_PLplotFrame_stream();
//frame->Create(...);
//frame->CreatePLplotstream();
//frame->Show();
one thing that caught my attention in your code was this way of handling
events
WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler(
wxPLplotwindow::OnSize ) );
I usually do a static event table, in fact all the wxWidgets samples do the
same, except
for some thread related code
but even using the static event table in your code, the bug still was there.
so the only way was to do an explicit call to
frame->CreatePLplotstream();
let me know if you have any questions
-Pedro
- Original Message -
From: "Pedro Vicente"
To: "Phil Rosenberg" ;
Sent: Saturday, December 10, 2016 11:25 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with
workaround
> Hi Phil
>
> There is actually a very simple solution.
> Instead of figuring out why the OnCreate event is not triggered in some
> linux cases, you can explicitally call that code with some function.
>
> I did just that, like this, where
> frame->CreatePLplotstream();
>
> is a function that contains your code that is in OnCreate()
>
> this makes it needed to a user to call this extra function, but well, you
> can't win them all
>
> this code below makes a plot in Windows and Linux
>
> Note:
> I did my own class
> wx_PLplotFrame
>
> that is virtually identical to wxPLplotwindow, but not templated
>
> I'll put this code in github when I have a chance later
>
> bool wxAppPlot::OnInit()
> {
> wx_PLplotFrame *frame = new wx_PLplotFrame();
> frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>wxDefaultPosition,
>wxSize(900, 700));
> frame->CreatePLplotstream();
> frame->Show();
> wxPLplotstream* pls = frame->GetStream();
> assert(pls);
> PLFLT x[4] = { 1, 2, 3, 4 };
> PLFLT y[4] = { 1, 2, 3, 4 };
> pls->env(0, 5, 0, 5, 0, 0);
> pls->line(4, x, y);
> return true;
> }
>
> -Pedro
>
>
> - Original Message -
> From: "Phil Rosenberg"
> To: "Pedro Vicente" ;
>
> Sent: Saturday, December 10, 2016 3:57 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
>> Hi Pedro
>> I have included the devel list on this email, so the thread will get
>> documented on the mailing list.
>>
>> It is very strange that the OnCreate function is not being called. If
>> you are calling Create then you should be generating a create event.
>> Am I correct in saying that you are getting this segfault with the
>> unchanged demo app?
>>
>> This location really is the best (and maybe only) place this
>> initialisation should be done. It cannot be included in the
>> constructor, because the generic nature of the template specification
>> means the code in the constructor does not know which type of wxWindow
>> we are inheriting from so cannot pass the correct parameters to the
>> constructor. By the time OnPaint is called it is really too late,
>> because we would like to already have the plot initialised and ready
>> to draw and it would be a real pain for you in your code if you had to
>> somehow wait for the first paint or resize event.
>>
>> I do have access to a CentOS machine at work, although I think I have
>> only got access to wxWidgets 2.8 on that system. I will check. I may
>> be able to build 3.1 from source. I presume you are using 3.1.0 as
>> released in February, rather than the head of the master branch?
>>
>> On 10 December 2016 at 07:52, Pedro Vicente
>> wrote:
>>> Hi Phil
>>>
>>> My idea for a fix is to move the stream initialization that is now on
>>>
>>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent &event
>>> {
>>> if ( !m_created )
>>>
>>> either to the OnSize or onPaint events
>>>
>>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>>
>>> and also in the plot call do this
>>>
>>> template< class WXWINDOW >
>>> void Plot( wxPLplotwindow *plotwindow )
>>> {
>>>wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>>if (pls == NULL)
>>>{
>>> return;
>>>}
>>>
>>>
>>> Like this , in this sequence
>>>
>>>
>>> wxPLplotwindow *frame = new wxPLplotwindow();
>>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>frame->SetIcon( wxIcon( graph ) );
>>>frame->Show();
>>>Plot( frame );
>>>
>>>
>>> first we go to
>>> Plot( frame );
>>>
>>> but the stream is NULL because
>>> :OnCreate
>>> was not called, but the function returns, avoiding the seg fault
>>>
>>> then the window gets a paint or size event, and the stream
>>> initialization
>>> code is called
>>> at this time I have a PLplot empty black window
>>>
>>> but because
>>> Plot( frame );
>>> was only called a
