plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] plplot_pyqt4 shared object build issue

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

On 2016-12-13 10:18-0000 Arjen Markus wrote:

> To get all the details, see the attached tarball.

Hi Arjen:

I have now had a chance to look at those detailed results (only for shared case
and only for ctest in build tree), and all seems fine.  And because
you specified

--do_submit_dashboard yes

as a comprehensive test option, there is a good summary of those ctest results at

http://my.cdash.org/index.php?project=PLplot_git

Such dashboards present what is typically a small part of
comprehensive tests (only the ctest results in the build tree) in a very
nice way so they complement the report tarballs.  But the latter have
a lot more information about all aspects of the comprehensive test so
I appreciate you continuing to use the above option as well as
continuing to send me the report tarballs.

Ironically, I forgot the above option on my big successful
comprehensive test yesterday, but I will remember from now on!

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_pyqt4 shared object build issue

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, December 13, 2016 12:13 PM
>
> I am very happy to hear that.  Big sigh of relief!
>
> Since I currently have comprehensive test success on Linux and you now also have
> that on Cygwin, would you be willing to follow up with a comprehensive test on
> MinGW-w64/MSYS2 and your spot checks on MSVC with ifort?
>
Sure, that should be no particular problem.

Hopefully I can do that today (just a whole bunch of things going on).

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_pyqt4 shared object build issue

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

On 2016-12-13 10:18-0000 Arjen Markus wrote:

> The short report is: your solution worked!

I am very happy to hear that.  Big sigh of relief!

Since I currently have comprehensive test success
on Linux and you now also have that
on Cygwin, would you be willing to follow up
with a comprehensive test on MinGW-w64/MSYS2
and your spot checks on MSVC with ifort?

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_pyqt4 shared object build issue

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> The short story is I am looking forward to your next report.
>
The short report is: your solution worked!

> Here is the longer story.
>
To get all the details, see the attached tarball.

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] build plplot using CMAKE using MSYS makefiles on windows 10

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

Thanks Greg,

with your patch linking problem is solved. Can you post an answer in 
this question 
https://forums.wxwidgets.org/viewtopic.php?f=19&t=42882&p=174262#p174262


Now there is still a problem in cmake process because I have to modify 
file 
plplot\buildmingw64\examples\c++\CMakeFiles\wxPLplotDemo.dir\linklibs.rsp 
to link wxPlplotDemo

in this file I have changed all  /f/lib/wxWidgets-3.1.0 in 
f:/lib/wxWidgets-3.1.0. May be it is not a bug in plot cmake but in cmake.


I can execute wxPlplotDemo.




Le 13/12/2016 à 07:18, Greg Jung a écrit :
> 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 
> <lau...@un... <mailto:lau...@un...>> 
> 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)'
>                   return FindTextW(lpfindreplace);
>                                                 ^
>     F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function
>     'HICON__*
>     LoadIcon(HINSTANCE, LPCTSTR)':
>     F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot
>     convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
>     for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
>                   return LoadIconW(hInstance, lpIconName);
>                                                         ^
>     F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function
>     'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
>     F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:324:55: error: cannot
>     convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
>     for argument '2' to 'HBITMAP__* LoadBitmapW(HINSTANCE, LPCWSTR)'
>                   return LoadBitmapW(hInstance, lpBitmapName);
>                                                             ^
>     make[2]: *** [src/CMakeFiles/plplot.dir/build.make:1114:
>     src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj] Error 1
>     make[1]: *** [CMakeFiles/Makefile2:546: src/CMakeFiles/plplot.dir/all]
>     Error 2
>     make: *** [Makefile:150: all] Error 2
>
>
>
>
>
>     Le 10/12/2016 à 02:11, Phil Rosenberg a écrit :
>     > 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?
>     >
>     > On 8 December 2016 at 16:37, Laurent Berger
>     > <lau...@un...
>     <mailto:lau...@un...>> wrote:
>     >> Hi,
>     >>
>     >> I want to buil plplot in static using MSYS makefiles on windows 10.
>     >>
>     >> In cmake GUI i have got an error that I cannot understand.
>     wxWidgets is
>     >> found but there is cmake_link_flags WARNING.
>     >>
>     >> Any help would be appreciate.
>     >>
>     >> CMake version = 3.7.0-rc2
>     >>
>     >> CMAKE_SYSTEM_NAME = Windows
>     >>
>     >> SH_EXECUTABLE = C:/Windows/System32/bash.exe....
>     >>
>     >> Looking for gdi32 header and library
>     >>
>     >> Looking for gdi32 header and library - found
>     >>
>     >> wxWidgets_FOUND : TRUE
>     >>
>     >> wxWidgets_INCLUDE_DIRS :
>     >>
>     F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.1;F:/lib/wxWidgets-3.1.0/include
>     >>
>     >> wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib
>     >>
>     >> wxWidgets_LIBRARIES :
>     >>
>     -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
>     >>
>     >> wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include
>     >>
>     >> wxWidgets_USE_FILE : UsewxWidgets
>     >>
>     >> 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
>     >>
>     >> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it
>     is set to
>     >> nothing to signal the failure of cmake_link_flags for the
>     original link
>     >> flags printed out above.
>     >>
>     >> WARNING: wxWidgets or its libraries not found so setting all
>     wxwidgets
>     >> devices to OFF.
>     >>
>     >> WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets
>     devices to OFF.
>     >>
>     >>
>     >>
>     ------------------------------------------------------------------------------
>     >> Developer Access Program for Intel Xeon Phi Processors
>     >> Access to Intel Xeon Phi processor-based developer platforms.
>     >> With one year of Intel Parallel Studio XE.
>     >> Training and support from Colfax.
>     >> Order your platform today.http://sdm.link/xeonphi
>     >> _______________________________________________
>     >> Plplot-devel mailing list
>     >> Plp...@li...
>     <mailto:Plp...@li...>
>     >> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>     <https://lists.sourceforge.net/lists/listinfo/plplot-devel>
>     >>
>
>
>     ------------------------------------------------------------------------------
>     Developer Access Program for Intel Xeon Phi Processors
>     Access to Intel Xeon Phi processor-based developer platforms.
>     With one year of Intel Parallel Studio XE.
>     Training and support from Colfax.
>     Order your platform today.http://sdm.link/xeonphi
>     _______________________________________________
>     Plplot-devel mailing list
>     Plp...@li...
>     <mailto:Plp...@li...>
>     https://lists.sourceforge.net/lists/listinfo/plplot-devel
>     <https://lists.sourceforge.net/lists/listinfo/plplot-devel>
>
>

Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with workaround

[Pedro V. <ped...@sp...>]

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<WXWINDOW>::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" <ped...@sp...>
To: "Phil Rosenberg" <p.d...@gm...>; 
<plp...@li...>
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" <p.d...@gm...>
> To: "Pedro Vicente" <ped...@sp...>;
> <plp...@li...>
> 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
>> <ped...@sp...> wrote:
>>> Hi Phil
>>>
>>> My idea for a fix is to move the stream initialization that is now  on
>>>
>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event
>>> {
>>> if ( !m_created )
>>>
>>> either to the OnSize or onPaint events
>>>
>>> void wxPLplotwindow<WXWINDOW>::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>>
>>> and also in the plot call do this
>>>
>>> template< class WXWINDOW >
>>> void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
>>> {
>>>    wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>>    if (pls == NULL)
>>>    {
>>>      return;
>>>    }
>>>
>>>
>>> Like this , in this sequence
>>>
>>>
>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>    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 at start, it is not called again, so there is no draw
>>>
>>> any ideas here ?
>>>
>>> of course making the Plot() call in another app function should work
>>>
>>>
>>> If you could replicate this issue, that would be great.
>>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: Pedro Vicente
>>> To: plp...@li... ; Phil Rosenberg
>>> Sent: Saturday, December 10, 2016 12:59 AM
>>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>>
>>>
>>> Hi Phil
>>>
>>> So, the issue seems to be the same that I have been reporting
>>>
>>>
>>> In the wxPLplotDemo.cpp code you have these callling functions
>>>
>>>
>>> wxPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>
>>>
>>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>>> all these calls are in the header file wxPLplotwindow.h
>>>
>>> first the constructor is called
>>>
>>> template<class WXWINDOW>
>>> wxPLplotwindow<WXWINDOW>::wxPLplotwindow( bool useGraphicsContext, 
>>> wxSize
>>> clientSize )
>>>    : m_created( false ), m_initialSize( clientSize )
>>>
>>>
>>> then this call OnCreate() is called, like you mentioned
>>> and the !m_created bool makes the initialization of the stream happen
>>>
>>> the problem is  that this function id *NOT* called on my linux build (it
>>> is
>>> on the Windows build)
>>> so therefore later
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>> this is NULL, so therefore it seg faults on the plot calls
>>>
>>> //! This is called when the widow is created i.e. after WXWINDOW::Create
>>> // has been called. We note that this has been called to avoid 
>>> attempting
>>> // to redraw a plot on a window that hasn't been created yet.
>>> template<class WXWINDOW>
>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>>> {
>>> if ( !m_created )
>>>
>>> so, one quick try is to put the code of
>>>
>>> void wxPLplotwindow<WXWINDOW>::OnCreate
>>> that is not called on the constructor maybe ?
>>>
>>> -Pedro
>>>
>>> ----- Original Message ----- From: Pedro Vicente
>>> To: plp...@li... ; Phil Rosenberg
>>> Sent: Friday, December 09, 2016 11:57 PM
>>> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>>>
>>>
>>> Hi Phil
>>>
>>> So, resuming the last thread about wxWidgets, what I did was to build 
>>> and
>>> run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8
>>>
>>> all builds fine, but when I do run , I get a seg fault
>>>
>>> [pedro.vicente@rhw9121 c++]$ cd
>>> /data/home002/pvicente/plplot/build/examples/c++
>>> [pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
>>> Segmentation fault
>>>
>>> I know that only this information is not much help to you to debug, but
>>> in
>>> the next couple of days I'll be debugging this and posting here any
>>> solution.
>>>
>>> my cmake call was
>>>
>>> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
>>> -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
>>> -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1d
>>> -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON
>>> -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0
>>> -DwxWidgets_LIB_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0/lib
>>> -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_TEST:BOOL=ON >& cmake.txt &
>>>
>>>
>>> the output of
>>> cmake
>>> and
>>> make
>>> are attached
>>>
>>> -Pedro
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>>
>>>
>>>
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>>
>>>
>>>
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10

[Greg J. <gv...@gm...>]

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 <
lau...@un...> 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)'
>               return FindTextW(lpfindreplace);
>                                             ^
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HICON__*
> LoadIcon(HINSTANCE, LPCTSTR)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
>               return LoadIconW(hInstance, lpIconName);
>                                                     ^
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function
> 'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:324:55: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HBITMAP__* LoadBitmapW(HINSTANCE, LPCWSTR)'
>               return LoadBitmapW(hInstance, lpBitmapName);
>                                                         ^
> make[2]: *** [src/CMakeFiles/plplot.dir/build.make:1114:
> src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj] Error 1
> make[1]: *** [CMakeFiles/Makefile2:546: src/CMakeFiles/plplot.dir/all]
> Error 2
> make: *** [Makefile:150: all] Error 2
>
>
>
>
>
> Le 10/12/2016 à 02:11, Phil Rosenberg a écrit :
> > 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?
> >
> > On 8 December 2016 at 16:37, Laurent Berger
> > <lau...@un...> wrote:
> >> Hi,
> >>
> >> I want to buil plplot in static using MSYS makefiles on windows 10.
> >>
> >> In cmake GUI i have got an error that I cannot understand. wxWidgets is
> >> found but there is cmake_link_flags WARNING.
> >>
> >> Any help would be appreciate.
> >>
> >> CMake version = 3.7.0-rc2
> >>
> >> CMAKE_SYSTEM_NAME = Windows
> >>
> >> SH_EXECUTABLE = C:/Windows/System32/bash.exe....
> >>
> >> Looking for gdi32 header and library
> >>
> >> Looking for gdi32 header and library - found
> >>
> >> wxWidgets_FOUND : TRUE
> >>
> >> wxWidgets_INCLUDE_DIRS :
> >> F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.
> 1;F:/lib/wxWidgets-3.1.0/include
> >>
> >> wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib
> >>
> >> wxWidgets_LIBRARIES :
> >> -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
> >>
> >> wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include
> >>
> >> wxWidgets_USE_FILE : UsewxWidgets
> >>
> >> 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
> >>
> >> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it is set
> to
> >> nothing to signal the failure of cmake_link_flags for the original link
> >> flags printed out above.
> >>
> >> WARNING: wxWidgets or its libraries not found so setting all wxwidgets
> >> devices to OFF.
> >>
> >> WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to
> OFF.
> >>
> >>
> >> ------------------------------------------------------------
> ------------------
> >> Developer Access Program for Intel Xeon Phi Processors
> >> Access to Intel Xeon Phi processor-based developer platforms.
> >> With one year of Intel Parallel Studio XE.
> >> Training and support from Colfax.
> >> Order your platform today.http://sdm.link/xeonphi
> >> _______________________________________________
> >> Plplot-devel mailing list
> >> Plp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >>
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10

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

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 <ir...@be...> wrote:
> On 2016-12-10 01:11-0000 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/version.dll;
> C:/Windows/System32/wsock32.dll;
> C:/Windows/System32/gdi32.dll
>
> The empty list elements in the first list are simply ignored.  But
> from the above broken down versions, I hope it is now clear that you
> have to install (or help CMake find) the libraries corresponding to
>
> -lwxregexu-3.1;
> -lwxexpat-3.1;
> -lwxtiff-3.1;
> -lwxjpeg-3.1;
> -lwxpng-3.1;
>
> and
> -luuid;
> -lwinspool;
>
> in the first list which ended up as _library_pathname-NOTFOUND; (i.e.,
> the corresponding library from the first list could not be found) in
> the transformed list.
>
> 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_pyqt4 shared object build issue

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

On 2016-12-12 08:30-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> 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
__________________________

Re: [Plplot-devel] plplot_pyqt4 shared object build issue

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

/****************************************************************************
** 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 <QObject>."
#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<MasterHandler *>(_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<void*>(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,       // flags
       0,       // signalCount

 // slots: signature, parameters, type, tag, flags
      18,   12,   11,   11, 0x09,
      48,   12,   11,   11, 0x09,
      80,   12,   11,   11, 0x09,
     109,   12,   11,   11, 0x09,
     135,   12,   11,   11, 0x09,
     160,   11,   11,   11, 0x09,

       0        // eod
};

static const char qt_meta_stringdata_QtPLWidget[] = {
    "QtPLWidget\0\0event\0mousePressEvent(QMouseEvent*)\0"
    "mouseReleaseEvent(QMouseEvent*)\0"
    "mouseMoveEvent(QMouseEvent*)\0"
    "keyPressEvent(QKeyEvent*)\0"
    "closeEvent(QCloseEvent*)\0nextPage()\0"
};

void QtPLWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a)
{
    if (_c == QMetaObject::InvokeMetaMethod) {
        Q_ASSERT(staticMetaObject.cast(_o));
        QtPLWidget *_t = static_cast<QtPLWidget *>(_o);
        switch (_id) {
        case 0: _t->mousePressEvent((*reinterpret_cast< QMouseEvent*(*)>(_a[1]))); break;
        case 1: _t->mouseReleaseEvent((*reinterpret_cast< QMouseEvent*(*)>(_a[1]))); break;
        case 2: _t->mouseMoveEvent((*reinterpret_cast< QMouseEvent*(*)>(_a[1]))); break;
        case 3: _t->keyPressEvent((*reinterpret_cast< QKeyEvent*(*)>(_a[1]))); break;
        case 4: _t->closeEvent((*reinterpret_cast< QCloseEvent*(*)>(_a[1]))); break;
        case 5: _t->nextPage(); break;
        default: ;
        }
    }
}

const QMetaObjectExtraData QtPLWidget::staticMetaObjectExtraData = {
    0,  qt_static_metacall 
};

const QMetaObject QtPLWidget::staticMetaObject = {
    { &QWidget::staticMetaObject, qt_meta_stringdata_QtPLWidget,
      qt_meta_data_QtPLWidget, &staticMetaObjectExtraData }
};

#ifdef Q_NO_DATA_RELOCATION
const QMetaObject &QtPLWidget::getStaticMetaObject() { return staticMetaObject; }
#endif //Q_NO_DATA_RELOCATION

const QMetaObject *QtPLWidget::metaObject() const
{
    return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject : &staticMetaObject;
}

void *QtPLWidget::qt_metacast(const char *_clname)
{
    if (!_clname) return 0;
    if (!strcmp(_clname, qt_meta_stringdata_QtPLWidget))
        return static_cast<void*>(const_cast< QtPLWidget*>(this));
    if (!strcmp(_clname, "QtPLDriver"))
        return static_cast< QtPLDriver*>(const_cast< QtPLWidget*>(this));
    return QWidget::qt_metacast(_clname);
}

int QtPLWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
    _id = QWidget::qt_metacall(_c, _id, _a);
    if (_id < 0)
        return _id;
    if (_c == QMetaObject::InvokeMetaMethod) {
        if (_id < 6)
            qt_static_metacall(this, _c, _id, _a);
        _id -= 6;
    }
    return _id;
}
static const uint qt_meta_data_QtExtWidget[] = {

 // content:
       6,       // revision
       0,       // classname
       0,    0, // classinfo
       3,   14, // methods
       0,    0, // properties
       0,    0, // enums/sets
       0,    0, // constructors
       0,       // flags
       0,       // signalCount

 // slots: signature, parameters, type, tag, flags
      19,   13,   12,   12, 0x0a,
      48,   13,   12,   12, 0x0a,
      80,   13,   12,   12, 0x0a,

       0        // eod
};

static const char qt_meta_stringdata_QtExtWidget[] = {
    "QtExtWidget\0\0event\0mouseMoveEvent(QMouseEvent*)\0"
    "mouseReleaseEvent(QMouseEvent*)\0"
    "mousePressEvent(QMouseEvent*)\0"
};

void QtExtWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a)
{
    if (_c == QMetaObject::InvokeMetaMethod) {
        Q_ASSERT(staticMetaObject.cast(_o));
        QtExtWidget *_t = static_cast<QtExtWidget *>(_o);
        switch (_id) {
        case 0: _t->mouseMoveEvent((*reinterpret_cast< QMouseEvent*(*)>(_a[1]))); break;
        case 1: _t->mouseReleaseEvent((*reinterpret_cast< QMouseEvent*(*)>(_a[1]))); break;
        case 2: _t->mousePressEvent((*reinterpret_cast< QMouseEvent*(*)>(_a[1]))); break;
        default: ;
        }
    }
}

const QMetaObjectExtraData QtExtWidget::staticMetaObjectExtraData = {
    0,  qt_static_metacall 
};

const QMetaObject QtExtWidget::staticMetaObject = {
    { &QtPLWidget::staticMetaObject, qt_meta_stringdata_QtExtWidget,
      qt_meta_data_QtExtWidget, &staticMetaObjectExtraData }
};

#ifdef Q_NO_DATA_RELOCATION
const QMetaObject &QtExtWidget::getStaticMetaObject() { return staticMetaObject; }
#endif //Q_NO_DATA_RELOCATION

const QMetaObject *QtExtWidget::metaObject() const
{
    return QObject::d_ptr->metaObject ? QObject::d_ptr->metaObject : &staticMetaObject;
}

void *QtExtWidget::qt_metacast(const char *_clname)
{
    if (!_clname) return 0;
    if (!strcmp(_clname, qt_meta_stringdata_QtExtWidget))
        return static_cast<void*>(const_cast< QtExtWidget*>(this));
    return QtPLWidget::qt_metacast(_clname);
}

int QtExtWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
    _id = QtPLWidget::qt_metacall(_c, _id, _a);
    if (_id < 0)
        return _id;
    if (_c == QMetaObject::InvokeMetaMethod) {
        if (_id < 3)
            qt_static_metacall(this, _c, _id, _a);
        _id -= 3;
    }
    return _id;
}
QT_END_MOC_NAMESPACE

Re: [Plplot-devel] No swig support for octave 4.2

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

On 2016-12-11 15:04-0700 Orion Poplawski wrote:

> Just a heads up that currently swig does not support octave 4.2.
[...]
> See https://github.com/swig/swig/issues/847

Hi Orion:

Thanks for that information.  I hope the octave developers respond to
your request for information for 4.2 in a timely way so you can pass
that on to the swig developers, and they can figure out how to adjust
(also in a timely way). As a Fedora packager you play a vital role
facilitating communication between two separate free software
development groups like this.  I sure appreciate your role here, and I
assume those groups do as well.  Keep up the good work!

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_pyqt4 shared object build issue

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

On 2016-12-11 15:04-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> DONE as of commit 6b01000.  I would appreciate you trying the identical
>> comprehensive test check on Cygwin to confirm the pyqt4 issue you were seeing is
>> now gone.
>>
> I did an update of the repository and ran the comprehensive test script (with X Window running and the parallel option turned off). The result was different from before, but there are still build errors - see the attached tarball.

Hi Arjen:

I view this issue as release critical so thanks for providing this
report so quickly during your weekend.

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.

Your report shows for this compilation both the USINGDLL and
qt_EXPORTS macros are set (as expected) and if you go through the
thicket of preprocessing logic in include/pldll.h.in, then

__declspec( dllimport )

should be used in a number of places in include/qt.h
(which is #included by the code in question and which makes use of
the PLDLLIMPEXP_QT macro which is #defined as above under these
circumstances).  So that _could_ explain
the warnings and eventual build failure.  But exactly the same logic holds for the compilation of
drivers/qt.cpp (both USINGDLL and qt_EXPORTS are set, and it includes
qt.h) and compilation of that code sailed through without any warnings
or errors.  Do you agree what happens for the compilation of
drivers/qt.cpp should also happen for the compilation of the
automoc-generated file

/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers/qt_automoc.cpp

or is there something you can spot that I am missing?

Also, two sets of eyes and two brains are better than one so
please send me the relevant generated files that cannot be compiled
there, i.e., the automoc-generated

/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers/qt_automoc.cpp

and the file it includes, the moc-generated

/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers/moc_qt.cpp

to see if I can spot anything as well.

While waiting for those files from you I plan to look at the report
you generated for your last successful Cygwin test (in July or so?)
where you built both the qt device driver and the plplotqt library
without issues.  Back then we were handling moc-generated files in an
entirely different way.  The present automoc-based methods should
provide essentially the same results but since they don't, that
comparison should provide some useful insight.

More later.

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] No swig support for octave 4.2

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

Just a heads up that currently swig does not support octave 4.2.  You 
get errors like:

[ 10%] Building CXX object 
bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
cd /builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave && 
/usr/lib64/ccache/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS 
-I/builddir/build/BUILD/plplot-5.11.1-7756f60/include 
-I/builddir/build/BUILD/plplot-5.11.1-7756f60/lib/qsastime 
-I/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora 
-I/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/include 
-I/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave 
-I/usr/include/octave-4.2.0 -I/usr/include/octave-4.2.0/octave 
-I/builddir/build/BUILD/plplot-5.11.1-7756f60/bindings/swig-support  -O2 
-g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-m64 -mtune=generic -fPIC   -o 
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c 
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
In file included from 
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
/usr/include/octave-4.2.0/octave/toplev.h:28:2: warning: #warning 
"toplev.h has been deprecated; use interpreter.h instead" [-Wcpp]
  #warning "toplev.h has been deprecated; use interpreter.h instead"
   ^~~~~~~
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: 
In function 'void SWIG_InstallBinaryOps(int, int)':
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: 
error: 'op_lshift' is not a member of 'octave_value'
  if 
(!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) 
\
                                               ^
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: 
note: in expansion of macro 'swigreg_binary_op'
      swigreg_binary_op(lshift);
      ^~~~~~~~~~~~~~~~~
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2100:43: 
error: 'op_lshift' is not a member of 'octave_value'
 
octave_value_typeinfo::register_binary_op(octave_value::op_##name,tid1,tid2,swig_binary_op_##name);
                                            ^
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: 
note: in expansion of macro 'swigreg_binary_op'
      swigreg_binary_op(lshift);
      ^~~~~~~~~~~~~~~~~
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: 
error: 'op_rshift' is not a member of 'octave_value'
  if 
(!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) 
\
                                               ^
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2148:5: 
note: in expansion of macro 'swigreg_binary_op'
      swigreg_binary_op(rshift);
      ^~~~~~~~~~~~~~~~~
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2100:43: 
error: 'op_rshift' is not a member of 'octave_value'
 
octave_value_typeinfo::register_binary_op(octave_value::op_##name,tid1,tid2,swig_binary_op_##name);
                                            ^
/builddir/build/BUILD/plplot-5.11.1-7756f60/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2148:5: 
note: in expansion of macro 'swigreg_binary_op'
      swigreg_binary_op(rshift);
      ^~~~~~~~~~~~~~~~~


See https://github.com/swig/swig/issues/847

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  or...@co...
Boulder, CO 80301              http://www.cora.nwra.com

Re: [Plplot-devel] plplot_pyqt4 shared object build issue

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> DONE as of commit 6b01000.  I would appreciate you trying the identical
> comprehensive test check on Cygwin to confirm the pyqt4 issue you were seeing is
> now gone.
>
I did an update of the repository and ran the comprehensive test script (with X Window running and the parallel option turned off). The result was different from before, but there are still build errors - see the attached tarball.

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] build plplot using CMAKE using MSYS makefiles on windows 10

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

On 2016-12-10 01:11-0000 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/version.dll;
C:/Windows/System32/wsock32.dll;
C:/Windows/System32/gdi32.dll

The empty list elements in the first list are simply ignored.  But
from the above broken down versions, I hope it is now clear that you
have to install (or help CMake find) the libraries corresponding to

-lwxregexu-3.1;
-lwxexpat-3.1;
-lwxtiff-3.1;
-lwxjpeg-3.1;
-lwxpng-3.1;

and
-luuid;
-lwinspool;

in the first list which ended up as _library_pathname-NOTFOUND; (i.e.,
the corresponding library from the first list could not be found) in
the transformed list.

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] Bump in freeze date and new estimate for release date

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

On 2016-12-10 01:57-0000 Phil Rosenberg wrote:

> I just wanted to check if it is too late to submit these [wxwidgets
bug fixes] now?

Hi Phil:

Go for it!  Also if you can pin down the exact system call that
creates the long pauses, there is a good chance there is a fix you can
implement for that, and I think in that case we would both want to
include that fix in the current release.

Also, I am in the peculiar position of being a developer pleading with
myself in the release manager's role for some more time to get some
more of my work matured enough to merge.  But as release manager, I
don't think letting the freeze date slide another week is
supercritical for us so I have granted AWI's request.  :-)

So this is official notice I am going to bump the freeze date by one
more week to December 17th.  This is primarily for my own development
needs (I still have a lot I would like to get into this release), but
this should allow you (and anybody else here) to add as many
complicated fixes as you can come up with this week.  And in any case,
simple bug fixes are certainly allowed after the freeze date right up
to the day of the release.

ETA of actual release will be roughly one week after I officially
declare the freeze has occurred, but as we have seen the ETA of that
freeze date is still pretty uncertain because there is still a lot I
would like to do, and some of it is a bit open-ended.  But if it turns
out I can really declare the official freeze on the 17th, then one
week later is Christmas Eve so to avoid that, Christmas day and Boxing
Day, the likely release date will be a few days after Christmas.  Of
course, that estimate of release date is still quite uncertain at this
moment, but we should know a lot more by the 17th.

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] wxPLplotDemo.cpp errors - FIXED , with workaround

[Pedro V. <ped...@sp...>]

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" <p.d...@gm...>
To: "Pedro Vicente" <ped...@sp...>; 
<plp...@li...>
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
> <ped...@sp...> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now  on
>>
>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow<WXWINDOW>::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
>> {
>>    wxPLplotstream* pls = plotwindow->GetStream();
>>
>>    if (pls == NULL)
>>    {
>>      return;
>>    }
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>    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 at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: Pedro Vicente
>> To: plp...@li... ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>>
>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>> all these calls are in the header file wxPLplotwindow.h
>>
>> first the constructor is called
>>
>> template<class WXWINDOW>
>> wxPLplotwindow<WXWINDOW>::wxPLplotwindow( bool useGraphicsContext, wxSize
>> clientSize )
>>    : m_created( false ), m_initialSize( clientSize )
>>
>>
>> then this call OnCreate() is called, like you mentioned
>> and the !m_created bool makes the initialization of the stream happen
>>
>> the problem is  that this function id *NOT* called on my linux build (it 
>> is
>> on the Windows build)
>> so therefore later
>> wxPLplotstream* pls = plotwindow->GetStream();
>>
>> this is NULL, so therefore it seg faults on the plot calls
>>
>> //! This is called when the widow is created i.e. after WXWINDOW::Create
>> // has been called. We note that this has been called to avoid attempting
>> // to redraw a plot on a window that hasn't been created yet.
>> template<class WXWINDOW>
>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>> {
>> if ( !m_created )
>>
>> so, one quick try is to put the code of
>>
>> void wxPLplotwindow<WXWINDOW>::OnCreate
>> that is not called on the constructor maybe ?
>>
>> -Pedro
>>
>> ----- Original Message ----- From: Pedro Vicente
>> To: plp...@li... ; Phil Rosenberg
>> Sent: Friday, December 09, 2016 11:57 PM
>> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, resuming the last thread about wxWidgets, what I did was to build and
>> run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8
>>
>> all builds fine, but when I do run , I get a seg fault
>>
>> [pedro.vicente@rhw9121 c++]$ cd
>> /data/home002/pvicente/plplot/build/examples/c++
>> [pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
>> Segmentation fault
>>
>> I know that only this information is not much help to you to debug, but 
>> in
>> the next couple of days I'll be debugging this and posting here any
>> solution.
>>
>> my cmake call was
>>
>> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
>> -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
>> -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1d
>> -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON
>> -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0
>> -DwxWidgets_LIB_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0/lib
>> -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_TEST:BOOL=ON >& cmake.txt &
>>
>>
>> the output of
>> cmake
>> and
>> make
>> are attached
>>
>> -Pedro
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>>
>>
>>
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>>
>>
>>
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] More on IPC

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

Hi (again) Phil:

Two further thoughts.

* All those preprocessing directives and fprintf calls I inserted make
it extremely hard to understand the code.  Thus, feel free to revert
my two commits completely that inserted the debug output in
PLMemoryMap:create and PLMemoryMap:close when you finally isolate
exactly what system call is causing the long pause.  But make that
reverting commit a clean one (nothing else then exactly reverting my
changes alone) to make it easy to reinstate my debug output again if
we ever need it again.  And I suggest you use a similar process for
the debugging printout you insert (i.e., one clean commit to put in
your own debug printout statements, one clean commit to remove that
code again once you finally isolate the issue).

* You will have to look at what your further debug print statements
say to get the definitive answer, but my current guess is a call from
-dev wxwidgets to some method of PLNamedMutex (or PLNamedMutexLocker)
will turn out to be the cause of the long-pause issue.

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] More on IPC

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

On 2016-12-10 13:21-0800 Alan W. Irwin wrote:

[...]
> So instead of pursuing this with inserting timing statements like you
> are thinking about, instead I plan to simply insert more debug prints,
> e.g., "PLMemoryMap::create: entering", PLMemoryMap::create: calling
> close" in the PLMemoryMap::create and PLMemoryMap::close code. With
> the idea I do a binary search to find exactly which system call is
> causing that long pause.  Of course, my initial result might be the
> long pause might not be in PLMemoryMap at all.  So we will see how
> this goes, and I hope to have some results for you in an hour or so
> from now.

Hi Phil:

See commit 7756f60 for the tonne of new debug print statements I have
inserted.

With those I got what appears naively to me is a "deadlock" situation
when attempting to delete m_name. (However, I emphasize naive because
I don't really understand C++ that well so I may be missing something
obvious).  Anyhow, I hope you will have a fast look at these results
and give me your comments on this "deadlock" and also my other
conclusions assuming it is not a deadlock at all.

First here are the results of the latest "two x01c example execution" test.

software@raven> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"
PLplot library version: 5.11.1
[from -dev wxwidgets?]
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustNotExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapSNULFSEKQE
PLMemoryMap::create: (mustNotExist) calling ftruncate
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
[from wxPLViewer?]
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapSNULFSEKQE
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
[from -dev wxwidgets?]
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapSNULFSEKQE
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name

real    0m0.280s
user    0m0.036s
sys     0m0.020s
done x01c
PLplot library version: 5.11.1
[from wxPLViewer]
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name
PLMemoryMap::close: just entering close
[long pause]
[from -dev wxwidgets?]
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustNotExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZUTHPBSHB
PLMemoryMap::create: (mustNotExist) calling ftruncate
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
[from wxPLViewer?]
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZUTHPBSHB
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
[from -dev wxwidgets?]
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapRZUTHPBSHB
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name

real    0m11.311s
user    0m0.048s
sys     0m0.008s
done x01c
[from wxPLViewer]
software@raven> PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name
PLMemoryMap::close: just entering close

As you can see from the above results and the commit, I have inserted debug printout almost
everywhere in PLMemoryMap::create and PLMemoryMap::close.  Note I have
tentatively (note question marks) identified which sections of output belong to -dev
wxwidgets and which to wxPLViewer (except after the "done x01c"
output it must be wxPLViewer so I have dropped the question
marks in those cases).  Do you agree with those identifications?

Also note that several times we have

PLMemoryMap::close: just entering close

with nothing happening in close afterwards meaning your if statements
are set up for that particular call to close in such a way that nothing is executed
in close.

Anyhow, the "deadlock" that concerns me is in the messages that must
be purely from wxPLViewer where just before the long pause we have

[from wxPLViewer]
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name
PLMemoryMap::close: just entering close

So it appears that wxPLViewer is executing its destructor, there is
an error there because shm_unlink has already been called by -dev
wxwidgets for that shared memory (but that is likely irrelevant, and near the
end of that process it finishes deleting m_name, but then that
destructor is called again afterwards.  Doesn't that cause a problem
or is that just naturally expected for C++ destructors?  If that is
expected, then that last message above corresponds to absolutely
nothing happening in the (last) destructor. Which means the long pause is due
to something else entirely than anything in PLMemoryMap::create or
PLMemoryMap::close!  Which would be some important progress in
finding the cause of the long pause, but there is more work to
do to nail this down.

Anyhow, this time I really have pretty much come to the end of how
much I can try additional print statements, but I could certainly act
as a sounding board in the days ahead as you figure out the exact
cause of the long pause.

But you should note the long pause occurs in the -dev wxwidgets code (i.e. not
PLViewer).  The first debug output after that long pause is

[from -dev wxwidgets?]
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustNotExist) calling shm_open

where that

PLMemoryMap::close: just entering close

with nothing further happening in close is the result of the close()
call at the start of PLMemoryMap::create, and the next printout occurs
just before the next system call (to shm_open in this case).  So these
results are a clear indication the long pause is caused by something happening
in the -dev wxwidgets code _before_ PLMemoryMap::create or
PLMemoryMap::close are even called.  So it is in that other code that
you should insert debug print statements or timing commands.

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] More on IPC

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

On 2016-12-10 13:41-0000 p.d...@gm... wrote:

> Many thanks Alan for pushing this and getting the debug statements into the code. You have confirmed that i was looking in the wrong place for the problem.
>
> I was mulling things over this morning and wondered about the same thing as you, some sort of memory leak with the shared memory. You have obviously shown that not to be the case.
>
> The error messages are a bit of a surprise. I would have thought that the memory map would count the number of system wide open calls that had been made and only close when all those open calls was matched with a close. I will have to check the documentation to be sure. Maybe this is related to the long delay somehow.
>
> I think the next step is probably to add some timing code to the viewer. My plan is to try to sort the other bugs i mentioned this evening. Then if there is still time I may try that.
>
> If you do anything else in the meantime then let me know so we can avoid duplicated effort.

Hi Phil:

I was just going to leave this issue to you until post-release because there
is lot of other stuff on my pre-release agenda, but if we could solve
this issue for the release it would be great so I am perfectly willing
to be flexible on the release timing if that will make a difference.
Also after I got some much-needed sleep I woke up just now with huge
curiosity about what is going on with the really obvious and reliably
generated long pause for the second (!) time an example is executed if
too close to the first execution.

So instead of pursuing this with inserting timing statements like you
are thinking about, instead I plan to simply insert more debug prints,
e.g., "PLMemoryMap::create: entering", PLMemoryMap::create: calling
close" in the PLMemoryMap::create and PLMemoryMap::close code. With
the idea I do a binary search to find exactly which system call is
causing that long pause.  Of course, my initial result might be the
long pause might not be in PLMemoryMap at all.  So we will see how
this goes, and I hope to have some results for you in an hour or so
from now.

Also, it strikes me that since Pedro is finding those segfaults on
three different Linux systems for his own work, clearly there is
something going on that is different for Linux compared to Windows,
and it might be related to this long pause issue I am investigating.

Meanwhile, I would appreciate it if you and everybody else here with
access to wxwidgets and Linux tried my experiment on Linux of

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"

just to make absolutely sure the reliable long pause (> 5 seconds and
often > 10 seconds) I am getting for this experiment is not just some
bug with a particular system call for the Debian Jessie version of
that and instead is there for all Linux systems we have access to
here.  Laurent confirmed the long pause with a somewhat similar
experiment a few weeks ago for a quite different Linux kernel (I have
forgotten the distribution), but it would be good to get confirmation
on a variety of Linux systems.

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] wxPLplotDemo.cpp errors

[Pedro V. <ped...@sp...>]

Hi Phil

I tested on a third Linux, with libwxgtk3.0-dev from package (the latest 
ubuntu package)

uname -a
Linux glace 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

then
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
sudo apt-get install libwxgtk3.0-dev
cd plplot-plplot/build/
cmake .. -DBUILD_TEST=ON -DENABLE_f95:BOOL=OFF
make
cd /home/pvicente/plplot-plplot/build/examples/c++
pvicente@glace:~/plplot-plplot/build/examples/c++$ ./wxPLplotDemo
Segmentation fault (core dumped)



----- Original Message ----- 
From: "Pedro Vicente" <ped...@sp...>
To: "Phil Rosenberg" <p.d...@gm...>; 
<plp...@li...>
Sent: Saturday, December 10, 2016 4:18 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


> Hi Phil
>
>>>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.
>
> What I usually do when I want to quick test on many unices , I install
> Virtual Box
>
> https://www.virtualbox.org/
>
> For example on my Windows PC I have a CentOS and Ubuntu as virtual guests
> (not the ones I did the PLplot test)
>
> -Pedro
>
>
>
>
> ----- Original Message ----- 
> From: "Phil Rosenberg" <p.d...@gm...>
> To: "Pedro Vicente" <ped...@sp...>;
> <plp...@li...>
> 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
>> <ped...@sp...> wrote:
>>> Hi Phil
>>>
>>> My idea for a fix is to move the stream initialization that is now  on
>>>
>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event
>>> {
>>> if ( !m_created )
>>>
>>> either to the OnSize or onPaint events
>>>
>>> void wxPLplotwindow<WXWINDOW>::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>>
>>> and also in the plot call do this
>>>
>>> template< class WXWINDOW >
>>> void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
>>> {
>>>    wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>>    if (pls == NULL)
>>>    {
>>>      return;
>>>    }
>>>
>>>
>>> Like this , in this sequence
>>>
>>>
>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>    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 at start, it is not called again, so there is no draw
>>>
>>> any ideas here ?
>>>
>>> of course making the Plot() call in another app function should work
>>>
>>>
>>> If you could replicate this issue, that would be great.
>>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: Pedro Vicente
>>> To: plp...@li... ; Phil Rosenberg
>>> Sent: Saturday, December 10, 2016 12:59 AM
>>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>>
>>>
>>> Hi Phil
>>>
>>> So, the issue seems to be the same that I have been reporting
>>>
>>>
>>> In the wxPLplotDemo.cpp code you have these callling functions
>>>
>>>
>>> wxPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>
>>>
>>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>>> all these calls are in the header file wxPLplotwindow.h
>>>
>>> first the constructor is called
>>>
>>> template<class WXWINDOW>
>>> wxPLplotwindow<WXWINDOW>::wxPLplotwindow( bool useGraphicsContext, 
>>> wxSize
>>> clientSize )
>>>    : m_created( false ), m_initialSize( clientSize )
>>>
>>>
>>> then this call OnCreate() is called, like you mentioned
>>> and the !m_created bool makes the initialization of the stream happen
>>>
>>> the problem is  that this function id *NOT* called on my linux build (it
>>> is
>>> on the Windows build)
>>> so therefore later
>>> wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>> this is NULL, so therefore it seg faults on the plot calls
>>>
>>> //! This is called when the widow is created i.e. after WXWINDOW::Create
>>> // has been called. We note that this has been called to avoid 
>>> attempting
>>> // to redraw a plot on a window that hasn't been created yet.
>>> template<class WXWINDOW>
>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>>> {
>>> if ( !m_created )
>>>
>>> so, one quick try is to put the code of
>>>
>>> void wxPLplotwindow<WXWINDOW>::OnCreate
>>> that is not called on the constructor maybe ?
>>>
>>> -Pedro
>>>
>>> ----- Original Message ----- From: Pedro Vicente
>>> To: plp...@li... ; Phil Rosenberg
>>> Sent: Friday, December 09, 2016 11:57 PM
>>> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>>>
>>>
>>> Hi Phil
>>>
>>> So, resuming the last thread about wxWidgets, what I did was to build 
>>> and
>>> run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8
>>>
>>> all builds fine, but when I do run , I get a seg fault
>>>
>>> [pedro.vicente@rhw9121 c++]$ cd
>>> /data/home002/pvicente/plplot/build/examples/c++
>>> [pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
>>> Segmentation fault
>>>
>>> I know that only this information is not much help to you to debug, but
>>> in
>>> the next couple of days I'll be debugging this and posting here any
>>> solution.
>>>
>>> my cmake call was
>>>
>>> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
>>> -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
>>> -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1d
>>> -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON
>>> -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0
>>> -DwxWidgets_LIB_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0/lib
>>> -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_TEST:BOOL=ON >& cmake.txt &
>>>
>>>
>>> the output of
>>> cmake
>>> and
>>> make
>>> are attached
>>>
>>> -Pedro
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>>
>>>
>>>
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>>
>>>
>>>
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles onwindows 10

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

Hi Laurent
So those errors seem to be caused by unicode issues. The native windows functions have ansi versions which accept 8bit strings and unicode versions which accept 16 bit wide strings. There is also a generic form of each which uses #ifdefs which call the ansi or unicode versions depending on whether _UNICODE is #defined. You can see from the w suffix that the wide version is being used, however 8bit strings appear to be being passed in from wxWidgets.

This is really rather surprising. wxWidgets hasn't really used ansi strings since v2.8. I have a feeling there may be a legacy option to build with ansi strings, but I haven't tried this, nor do i know how well it works.

Is it possible you have built or attempted to build the ansi version of wxWidgets and somewhere it is getting confused?

Phil

Sent from my Windows 10 phone

From: Laurent Berger
Sent: 10 December 2016 14:58
To: Phil Rosenberg
Cc: PLplot development list
Subject: Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles onwindows 10

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)'
              return FindTextW(lpfindreplace);
                                            ^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HICON__* 
LoadIcon(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot 
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' 
for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
              return LoadIconW(hInstance, lpIconName);
                                                    ^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 
'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:324:55: error: cannot 
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' 
for argument '2' to 'HBITMAP__* LoadBitmapW(HINSTANCE, LPCWSTR)'
              return LoadBitmapW(hInstance, lpBitmapName);
                                                        ^
make[2]: *** [src/CMakeFiles/plplot.dir/build.make:1114: 
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:546: src/CMakeFiles/plplot.dir/all] 
Error 2
make: *** [Makefile:150: all] Error 2





Le 10/12/2016 à 02:11, Phil Rosenberg a écrit :
> 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?
>
> On 8 December 2016 at 16:37, Laurent Berger
> <lau...@un...> wrote:
>> Hi,
>>
>> I want to buil plplot in static using MSYS makefiles on windows 10.
>>
>> In cmake GUI i have got an error that I cannot understand. wxWidgets is
>> found but there is cmake_link_flags WARNING.
>>
>> Any help would be appreciate.
>>
>> CMake version = 3.7.0-rc2
>>
>> CMAKE_SYSTEM_NAME = Windows
>>
>> SH_EXECUTABLE = C:/Windows/System32/bash.exe....
>>
>> Looking for gdi32 header and library
>>
>> Looking for gdi32 header and library - found
>>
>> wxWidgets_FOUND : TRUE
>>
>> wxWidgets_INCLUDE_DIRS :
>> F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.1;F:/lib/wxWidgets-3.1.0/include
>>
>> wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib
>>
>> wxWidgets_LIBRARIES :
>> -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
>>
>> wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include
>>
>> wxWidgets_USE_FILE : UsewxWidgets
>>
>> 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
>>
>> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it is set to
>> nothing to signal the failure of cmake_link_flags for the original link
>> flags printed out above.
>>
>> WARNING: wxWidgets or its libraries not found so setting all wxwidgets
>> devices to OFF.
>>
>> WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10

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

An error in path but error is still here :


      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/lib"
          NO_DEFAULT_PATH
         )

and make clean and make gives


  make
[  1%] Building C object lib/csa/CMakeFiles/csirocsa.dir/csa.c.obj
[  3%] Linking C static library libcsirocsa.a
[  3%] Built target csirocsa
[  3%] Building C object 
lib/qsastime/CMakeFiles/deltaT-gen.dir/deltaT-gen.c.obj
[  4%] Building C object 
lib/qsastime/CMakeFiles/deltaT-gen.dir/dspline.c.obj
[  6%] Linking C executable deltaT-gen.exe
[  6%] Built target deltaT-gen
[  7%] Generating deltaT.h
[  7%] Built target deltaT.h_built
[  9%] Building C object 
lib/qsastime/CMakeFiles/tai-utc-gen.dir/tai-utc-gen.c.obj
[  9%] Linking C executable tai-utc-gen.exe
[  9%] Built target tai-utc-gen
[ 10%] Generating tai-utc.h
[ 10%] Built target tai-utc.h_built
Scanning dependencies of target qsastime
[ 12%] Building C object lib/qsastime/CMakeFiles/qsastime.dir/qsastime.c.obj
[ 13%] Building C object lib/qsastime/CMakeFiles/qsastime.dir/dsplint.c.obj
[ 15%] Linking C static library libqsastime.a
[ 15%] Built target qsastime
[ 15%] Building C object 
include/CMakeFiles/plhershey-unicode-gen.dir/__/fonts/plhershey-unicode-gen.c.obj
[ 16%] Linking C executable plhershey-unicode-gen.exe
[ 16%] Built target plhershey-unicode-gen
[ 18%] Generating plhershey-unicode.h
[ 18%] Built target plhershey-unicode.h_built
Scanning dependencies of target plplot
[ 19%] Building C object src/CMakeFiles/plplot.dir/pdfutils.c.obj
[ 21%] Building C object src/CMakeFiles/plplot.dir/plmem.c.obj
[ 21%] Building C object src/CMakeFiles/plplot.dir/plaffine.c.obj
[ 22%] Building C object src/CMakeFiles/plplot.dir/plarc.c.obj
[ 24%] Building C object src/CMakeFiles/plplot.dir/plargs.c.obj
[ 25%] Building C object src/CMakeFiles/plplot.dir/plbox.c.obj
[ 27%] Building C object src/CMakeFiles/plplot.dir/plcont.c.obj
[ 28%] Building C object src/CMakeFiles/plplot.dir/plcore.c.obj
[ 28%] Building C object src/CMakeFiles/plplot.dir/plctrl.c.obj
[ 30%] Building C object src/CMakeFiles/plplot.dir/plcvt.c.obj
[ 31%] Building C object src/CMakeFiles/plplot.dir/pldtik.c.obj
[ 33%] Building C object src/CMakeFiles/plplot.dir/plf2ops.c.obj
[ 34%] Building C object src/CMakeFiles/plplot.dir/plfill.c.obj
[ 34%] Building C object src/CMakeFiles/plplot.dir/plfreetype.c.obj
[ 36%] Building C object src/CMakeFiles/plplot.dir/plgradient.c.obj
[ 37%] Building C object src/CMakeFiles/plplot.dir/plhist.c.obj
[ 39%] Building C object src/CMakeFiles/plplot.dir/plimage.c.obj
[ 40%] Building C object src/CMakeFiles/plplot.dir/plline.c.obj
[ 40%] Building C object src/CMakeFiles/plplot.dir/plmetafile.c.obj
[ 42%] Building C object src/CMakeFiles/plplot.dir/plot3d.c.obj
[ 43%] Building C object src/CMakeFiles/plplot.dir/plpage.c.obj
[ 45%] Building C object src/CMakeFiles/plplot.dir/plsdef.c.obj
[ 46%] Building C object src/CMakeFiles/plplot.dir/plshade.c.obj
[ 48%] Building C object src/CMakeFiles/plplot.dir/plstdio.c.obj
[ 48%] Building C object src/CMakeFiles/plplot.dir/plstripc.c.obj
[ 50%] Building C object src/CMakeFiles/plplot.dir/plsym.c.obj
[ 51%] Building C object src/CMakeFiles/plplot.dir/pltick.c.obj
[ 53%] Building C object src/CMakeFiles/plplot.dir/plvpor.c.obj
[ 54%] Building C object src/CMakeFiles/plplot.dir/plwind.c.obj
[ 54%] Building C object src/CMakeFiles/plplot.dir/plbuf.c.obj
[ 56%] Building C object src/CMakeFiles/plplot.dir/plgridd.c.obj
[ 57%] Building C object src/CMakeFiles/plplot.dir/plvect.c.obj
[ 59%] Building C object src/CMakeFiles/plplot.dir/mt19937ar.c.obj
[ 60%] Building C object src/CMakeFiles/plplot.dir/pltime.c.obj
[ 60%] Building C object src/CMakeFiles/plplot.dir/pllegend.c.obj
[ 62%] Building C object src/CMakeFiles/plplot.dir/plmap.c.obj
[ 63%] Building C object src/CMakeFiles/plplot.dir/__/drivers/mem.c.obj
[ 65%] Building C object src/CMakeFiles/plplot.dir/__/drivers/null.c.obj
[ 66%] Building C object src/CMakeFiles/plplot.dir/__/drivers/ps.c.obj
[ 68%] Building C object src/CMakeFiles/plplot.dir/__/drivers/svg.c.obj
[ 68%] Building C object src/CMakeFiles/plplot.dir/__/drivers/wingcc.c.obj
[ 69%] Building CXX object 
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets.cpp.obj
[ 71%] 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)'
              return FindTextW(lpfindreplace);
                                            ^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HICON__* 
LoadIcon(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot 
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' 
for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
              return LoadIconW(hInstance, lpIconName);
                                                    ^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 
'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:324:55: error: cannot 
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' 
for argument '2' to 'HBITMAP__* LoadBitmapW(HINSTANCE, LPCWSTR)'
              return LoadBitmapW(hInstance, lpBitmapName);
                                                        ^
make[2]: *** [src/CMakeFiles/plplot.dir/build.make:1114: 
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:546: src/CMakeFiles/plplot.dir/all] 
Error 2
make: *** [Makefile:150: all] Error 2


Le 10/12/2016 à 15:58, Laurent Berger a écrit :
> 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)'
>                return FindTextW(lpfindreplace);
>                                              ^
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HICON__*
> LoadIcon(HINSTANCE, LPCTSTR)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
>                return LoadIconW(hInstance, lpIconName);
>                                                      ^
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function
> 'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
> F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:324:55: error: cannot
> convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}'
> for argument '2' to 'HBITMAP__* LoadBitmapW(HINSTANCE, LPCWSTR)'
>                return LoadBitmapW(hInstance, lpBitmapName);
>                                                          ^
> make[2]: *** [src/CMakeFiles/plplot.dir/build.make:1114:
> src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj] Error 1
> make[1]: *** [CMakeFiles/Makefile2:546: src/CMakeFiles/plplot.dir/all]
> Error 2
> make: *** [Makefile:150: all] Error 2
>
>
>
>
>
> Le 10/12/2016 à 02:11, Phil Rosenberg a écrit :
>> 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?
>>
>> On 8 December 2016 at 16:37, Laurent Berger
>> <lau...@un...> wrote:
>>> Hi,
>>>
>>> I want to buil plplot in static using MSYS makefiles on windows 10.
>>>
>>> In cmake GUI i have got an error that I cannot understand. wxWidgets is
>>> found but there is cmake_link_flags WARNING.
>>>
>>> Any help would be appreciate.
>>>
>>> CMake version = 3.7.0-rc2
>>>
>>> CMAKE_SYSTEM_NAME = Windows
>>>
>>> SH_EXECUTABLE = C:/Windows/System32/bash.exe....
>>>
>>> Looking for gdi32 header and library
>>>
>>> Looking for gdi32 header and library - found
>>>
>>> wxWidgets_FOUND : TRUE
>>>
>>> wxWidgets_INCLUDE_DIRS :
>>> F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.1;F:/lib/wxWidgets-3.1.0/include
>>>
>>> wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib
>>>
>>> wxWidgets_LIBRARIES :
>>> -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
>>>
>>> wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include
>>>
>>> wxWidgets_USE_FILE : UsewxWidgets
>>>
>>> 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
>>>
>>> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it is set to
>>> nothing to signal the failure of cmake_link_flags for the original link
>>> flags printed out above.
>>>
>>> WARNING: wxWidgets or its libraries not found so setting all wxwidgets
>>> devices to OFF.
>>>
>>> WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] build plplot using CMAKE using MSYS makefiles on windows 10

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

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)'
              return FindTextW(lpfindreplace);
                                            ^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 'HICON__* 
LoadIcon(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:311:51: error: cannot 
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' 
for argument '2' to 'HICON__* LoadIconW(HINSTANCE, LPCWSTR)'
              return LoadIconW(hInstance, lpIconName);
                                                    ^
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h: In function 
'HBITMAP__* LoadBitmap(HINSTANCE, LPCTSTR)':
F:/lib/wxWidgets-3.1.0/include/wx/msw/winundef.h:324:55: error: cannot 
convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const wchar_t*}' 
for argument '2' to 'HBITMAP__* LoadBitmapW(HINSTANCE, LPCWSTR)'
              return LoadBitmapW(hInstance, lpBitmapName);
                                                        ^
make[2]: *** [src/CMakeFiles/plplot.dir/build.make:1114: 
src/CMakeFiles/plplot.dir/__/drivers/wxwidgets_comms.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:546: src/CMakeFiles/plplot.dir/all] 
Error 2
make: *** [Makefile:150: all] Error 2





Le 10/12/2016 à 02:11, Phil Rosenberg a écrit :
> 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?
>
> On 8 December 2016 at 16:37, Laurent Berger
> <lau...@un...> wrote:
>> Hi,
>>
>> I want to buil plplot in static using MSYS makefiles on windows 10.
>>
>> In cmake GUI i have got an error that I cannot understand. wxWidgets is
>> found but there is cmake_link_flags WARNING.
>>
>> Any help would be appreciate.
>>
>> CMake version = 3.7.0-rc2
>>
>> CMAKE_SYSTEM_NAME = Windows
>>
>> SH_EXECUTABLE = C:/Windows/System32/bash.exe....
>>
>> Looking for gdi32 header and library
>>
>> Looking for gdi32 header and library - found
>>
>> wxWidgets_FOUND : TRUE
>>
>> wxWidgets_INCLUDE_DIRS :
>> F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.1;F:/lib/wxWidgets-3.1.0/include
>>
>> wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib
>>
>> wxWidgets_LIBRARIES :
>> -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
>>
>> wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include
>>
>> wxWidgets_USE_FILE : UsewxWidgets
>>
>> 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
>>
>> cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it is set to
>> nothing to signal the failure of cmake_link_flags for the original link
>> flags printed out above.
>>
>> WARNING: wxWidgets or its libraries not found so setting all wxwidgets
>> devices to OFF.
>>
>> WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>

Re: [Plplot-devel] More on IPC

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

Many thanks Alan for pushing this and getting the debug statements into the code. You have confirmed that i was looking in the wrong place for the problem.

I was mulling things over this morning and wondered about the same thing as you, some sort of memory leak with the shared memory. You have obviously shown that not to be the case.

The error messages are a bit of a surprise. I would have thought that the memory map would count the number of system wide open calls that had been made and only close when all those open calls was matched with a close. I will have to check the documentation to be sure. Maybe this is related to the long delay somehow.

I think the next step is probably to add some timing code to the viewer. My plan is to try to sort the other bugs i mentioned this evening. Then if there is still time I may try that.

If you do anything else in the meantime then let me know so we can avoid duplicated effort.

Thanks again

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 10 December 2016 13:00
To: Phil Rosenberg
Cc: PLplot development list
Subject: Re: More on IPC

Hi Phil:

If you review my results from much earlier this year that had a screen
shot attached in the next e-mail of my cpumeter results, the test
being run was for a case with absolutely no text data being written to
wxPLViewer.  So your concern (expressed off list to me) about the
efficiency of IPC of text may be well taken, but they are not relevant
to this particular result of huge idle times.

Your other thought that inefficient IPC method may not be the direct
cause of this issue is likely correct.  For why, read on.

One working hypothesis I could think of to generate these
excessive idle times on Linux is that shared memory is not being
shm_unlink'd properly so we have a shared memory leak that in a
heavy-duty testing environment (such as when building the
test_c_wxwidgets target) means the Linux kernel is soon right up
against it (since it probably only allows a rather small proportion of
actual memory to be used for the special purpose of shared memory). So
the extraordinary measures that would be needed to supply shared memory ==>
huge idle times.

To investigate that possibility further I introduced (as of commit
dcae24e) rudimentary but proper debug reporting of when the creation
of shared memory is a success.  I also did that for the shm_unlink
call (but only for the case when there is success for
PLMemoryMap::create followed by a call to PLMemoryMap::close).  The
results from building the test_c_wxwidgets target (before I ^C'd out
of it) are as follows:

Testing subset of C examples for device wxwidgets
x01c
PLMemoryMap::create: shm_open was a success for plplotMemoryMapIFWDQVRLBF
PLMemoryMap::create: shm_open was a success for plplotMemoryMapIFWDQVRLBF
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapIFWDQVRLBF
x04c
PLMemoryMap::create: shm_open was a success for plplotMemoryMapBTDCASTECJ
PLMemoryMap::create: shm_open was a success for plplotMemoryMapBTDCASTECJ
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapBTDCASTECJ
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
x08c
PLMemoryMap::create: shm_open was a success for plplotMemoryMapYKNFFXNKGJ
PLMemoryMap::create: shm_open was a success for plplotMemoryMapYKNFFXNKGJ
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapYKNFFXNKGJ
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
x14c
PLMemoryMap::create: shm_open was a success for plplotMemoryMapNYBYKUHKXR
PLMemoryMap::create: shm_open was a success for plplotMemoryMapNYBYKUHKXR
PLMemoryMap::create: shm_open was a success for plplotMemoryMapIJIAMCSBUP
PLMemoryMap::create: shm_open was a success for plplotMemoryMapIJIAMCSBUP
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapIJIAMCSBUP
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapNYBYKUHKXR
x16c
PLMemoryMap::create: shm_open was a success for plplotMemoryMapQPXDPGRVTF
PLMemoryMap::create: shm_open was a success for plplotMemoryMapQPXDPGRVTF
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapQPXDPGRVTF
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
x17c
^C

So these results completely shoot down that hypothesis because for every
successful shm_open of a particular name there is also a successful
shm_unlink for that same name ==> no shared memory leak!  Oh well, on
to the next idea.  :-)

For a bit I was excited about the above shm_unlink error
messages that are also emitted for all but the first and 14th
examples, but I now believe that pattern is the expected one, i.e.,
-dev wxwidgets finishes so it calls the PLMemoryMap destructor 
or PLMemoryMap::close directly which
destroys the shared memory.  Then wxPLViewer finishes so when it calls
the PLMemoryMap destructor or PLMemoryMap::close directly those error messages must be emitted.
But I frankly do not understand why no such error messages were emitted
for the first and 14th examples.  Yet for the first example
experiments below, the error messages are always emitted.  I have
rerun both types of tests any number of times and these patterns
always repeat.  But I cannot figure out why different error messages are
emitted for x01c results
in the two contexts.  Do you have some intelligent guess or even
definitive response about that?

Note the above form of results always take a very long time to create so the
excessive idle time is still with us.  In fact to see that directly,
I ran x01c twice in a row as follows:

software@raven> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"
PLplot library version: 5.11.1
PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZZQSYHRAO
PLMemoryMap::create: shm_open was a success for plplotMemoryMapRZZQSYHRAO
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapRZZQSYHRAO

real    0m0.258s
user    0m0.040s
sys     0m0.016s
done x01c
PLplot library version: 5.11.1
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
[~10 second pause]
PLMemoryMap::create: shm_open was a success for plplotMemoryMapOLMHNIFOPT
PLMemoryMap::create: shm_open was a success for plplotMemoryMapOLMHNIFOPT
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapOLMHNIFOPT

real    0m10.263s
user    0m0.052s
sys     0m0.004s
done x01c
software@raven> PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory

I then did the same experiment only using -dev psc for the second
invocation of the example.

software@raven> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev psc -o test.ps ;echo "done x01c"
PLplot library version: 5.11.1
PLMemoryMap::create: shm_open was a success for plplotMemoryMapMAMYNDBJMT
PLMemoryMap::create: shm_open was a success for plplotMemoryMapMAMYNDBJMT
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapMAMYNDBJMT

real    0m0.255s
user    0m0.052s
sys     0m0.000s
done x01c
PLplot library version: 5.11.1

real    0m0.006s
user    0m0.004s
sys     0m0.000s
done x01c
software@raven> PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory

So absolutely no delay of that second example run in this case (as
expected), but a ~10 second delay (sigh) when -dev wxwidgets is used
twice in a row.

This ~10 second pause of the second example run for -dev wxwidgets occurred when no
wxPLViewer GUI was showing.  And from the placement of that pause
it is now a certainty that the delay is due to a long
wait (likely for some system resources) by the -dev wxwidgets code on startup, and the
most likely candidate for that is that delay is occurring somewhere in
PLMemoryMap::create.  So further debug output is going to have to be
inserted to confirm that, but if that turns out to be the case, this
obviously has nothing to do with IPC methods but everything to do with
setting those up.
Note also this issue is exactly the one I posted about a long time
ago, i.e., it also occurs when no text is being written to the device.

Unfortunately, I have now run out of any further time to pursue this
right now so the answer to the above question about whether or not the
issue is somewhere in PLMemoryMap::create and if so finding the exact
system call that is intermittently inserting huge delays will have to
be a mystery until post-release (unless someone else steps in).

I have now made a subsequent commit (1627eec) to drop this debug
information for the release.  But output of that useful debug
information can trivially be restored by #defining PLMemoryMap_DEBUG
in drivers/wxwidgets_comms.h.

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
__________________________