Re: [Plplot-devel] wingcc and wingdi build bugs

[Jim Dishaw]

> On Jan 14, 2018, at 4:30 PM, Greg Jung  wrote:
> 
> Hi Jim,
>   I've looked at the wingdi I was earlier working with, and the 
> commoncontrols initialization was commented out
> for the #ifdef _WIN64 case.  I'm unsure whether I tested with w64, I think 
> so.  But in the current attempt, I 
> was definitely confined to a 32-bit system - it may be the case that this 
> function is unavailable.
> 
> in module wingdi_modul_initialize( void ) :
> #ifdef _WIN64
>   
>   // Initialize common controls
>   init_controls.dwSize = sizeof(INITCOMMONCONTROLSEX);
>   init_controls.dwICC = ICC_BAR_CLASSES;
>   if( ! InitCommonControlsEx( _controls ) )
>   {
>   plwarn( "wingdi:  Failed to initialize common Window 
> controls\n" );
>   }
> #endif
> 

The InitCommonControlsEx is available in both WIN32 and WIN64.  When I was 
looking at how to patch, the minimum supported version is Windows Vista and it 
is also available in Wine.  I guess the main question is what is the minimum 
version of Windows that we want to support in Plplot.  I would say Windows 
Vista is the minimum because it is becoming more of a challenge to keep 
supporting XP (particularly when I need to test).  If I had a preference, I 
would draw the line at Windows 7 and 10 with Windows 8 being unsupported.

I am not sure why your cmake failed, because it should have worked.

>   Also to mention, it would be a great convenience if HWND - plot and HDC - 
> hdc were again placed at the top of 
> the wingdi_Dev struct.   As such, the replacement of wingcc with wingdi is 
> already accommodated in GDL as a compile-time macro.
> // Device-specific info per stream
> struct wingdi_Dev
> {
>   //
> // WIN32 API variables
> //
>   HWND  plot;   // Handle for the plot area
>   HDC   hdc;// Plot window device context
>   HPEN  pen;// Current pen used for drawing
>   …

That seems reasonable.  No real reason why I put them down lower other than a 
desire to put some common members at the top.

> Thanks,
> Greg
> 
> On Sun, Dec 31, 2017 at 5:14 AM, Jim Dishaw  > wrote:
> I think that is a Windows vs Windows 8. I will look at that today and patch. 
> 
> On Dec 31, 2017, at 1:10 AM, Greg Jung  > wrote:
> 
>> Hi guys,
>>Because my main PC (win 7) is busted I am working with a backup system 
>> which is windows 8.1 pro 32-bits
>> and I was interested in deploying the new wingdi for GDL on windows.  
>> Although no errors were anticipated from the
>>  cmake processing (required setting  PLD_wingdi=ON) the build came up short 
>> finding a library:
>> Scanning dependencies of target wingdi
>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>> [ 67%] Linking C shared module ../dll/wingdi.dll
>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7): 
>> undefined reference to `_imp__InitCommonControlsEx@4'
>> collect2.exe: error: ld returned 1 exit status
>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104: dll/wingdi.dll] 
>> Error 1
>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all] 
>> Error 2
>> make: *** [Makefile:152: all] Error 2
>> 
>> I also found, although it isn't important for me downstream, that my QHULL 
>> installation was not found correctly. I checked where they were to be found, 
>> here is a partial listing of that:
>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>> %FILES%
>> mingw32/
>> mingw32/bin/
>> mingw32/bin/qconvex.exe
>> mingw32/bin/qdelaunay.exe
>> mingw32/bin/qhalf.exe
>> mingw32/bin/qhull.exe
>> mingw32/bin/qvoronoi.exe
>> mingw32/bin/rbox.exe
>> mingw32/include/
>> mingw32/include/qhull/
>> mingw32/include/qhull/geom.h
>> mingw32/include/qhull/libqhull.h
>> 
>> 
>> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin > > wrote:
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>> 
>> Given that the libraries in question are in the standard c and C++
>> libraries. I just tested to see what the impact is of simply
>> commenting out the checks for these two libraries.
>> 
>> The result is that wingcc is accepted onto the driver list, appears in
>> my plplot VC++ project, everything builds correctly and I can run the
>> examples and select the wingcc device and everything runs fine.
>> 
>> Given that this is the case is there even a need to check for these
>> libraries? Or is this test needed for Cygwin or minGW builds?
>> 
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it.  On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that.  So before making any 

Re: [Plplot-devel] wingcc and wingdi build bugs

[Greg Jung]

Hi Jim,
  I've looked at the wingdi I was earlier working with, and the
commoncontrols initialization was commented out
for the #ifdef _WIN64 case.  I'm unsure whether I tested with w64, I think
so.  But in the current attempt, I
was definitely confined to a 32-bit system - it may be the case that this
function is unavailable.

in module wingdi_modul_initialize( void ) :

> #ifdef _WIN64
>
> // Initialize common controls
>
> init_controls.dwSize = sizeof(INITCOMMONCONTROLSEX);
>
> init_controls.dwICC = ICC_BAR_CLASSES;
>
> if( ! InitCommonControlsEx( _controls ) )
>
> {
>
> plwarn( "wingdi:  Failed to initialize common Window controls\n" );
>
> }
>
> #endif
>
>
>   Also to mention, it would be a great convenience if HWND - plot and HDC
- hdc were again placed at the top of
the wingdi_Dev struct.   As such, the replacement of wingcc with wingdi is
already accommodated in GDL as a compile-time macro.

> // Device-specific info per stream
>
> struct wingdi_Dev
>
> {
>
> //
>
> // WIN32 API variables
>
> //
>
> HWNDplot;   // Handle for the plot area
>
> HDC   hdc;// Plot window device context
>
> HPEN  pen;// Current pen used for drawing
>
>   ...
Thanks,
Greg

On Sun, Dec 31, 2017 at 5:14 AM, Jim Dishaw  wrote:

> I think that is a Windows vs Windows 8. I will look at that today and
> patch.
>
> On Dec 31, 2017, at 1:10 AM, Greg Jung  wrote:
>
> Hi guys,
>Because my main PC (win 7) is busted I am working with a backup system
> which is windows 8.1 pro 32-bits
> and I was interested in deploying the new wingdi for GDL on windows.
> Although no errors were anticipated from the
>  cmake processing (required setting  PLD_wingdi=ON) the build came up
> short finding a library:
>
>> Scanning dependencies of target wingdi
>>
>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>>
>> [ 67%] Linking C shared module ../dll/wingdi.dll
>>
>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7):
>>> undefined reference to `_imp__InitCommonControlsEx@4'
>>
>> collect2.exe: error: ld returned 1 exit status
>>
>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104:
>>> dll/wingdi.dll] Error 1
>>
>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all]
>>> Error 2
>>
>> make: *** [Makefile:152: all] Error 2
>>
>>
> I also found, although it isn't important for me downstream, that my QHULL
> installation was not found correctly. I checked where they were to be
> found, here is a partial listing of that:
>
>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>>
>> %FILES%
>>
>> mingw32/
>>
>> mingw32/bin/
>>
>> mingw32/bin/qconvex.exe
>>
>> mingw32/bin/qdelaunay.exe
>>
>> mingw32/bin/qhalf.exe
>>
>> mingw32/bin/qhull.exe
>>
>> mingw32/bin/qvoronoi.exe
>>
>> mingw32/bin/rbox.exe
>>
>> mingw32/include/
>>
>> mingw32/include/qhull/
>>
>> mingw32/include/qhull/geom.h
>>
>> mingw32/include/qhull/libqhull.h
>>
>>
>>
> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin 
> wrote:
>
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>>
>> Given that the libraries in question are in the standard c and C++
>>> libraries. I just tested to see what the impact is of simply
>>> commenting out the checks for these two libraries.
>>>
>>> The result is that wingcc is accepted onto the driver list, appears in
>>> my plplot VC++ project, everything builds correctly and I can run the
>>> examples and select the wingcc device and everything runs fine.
>>>
>>> Given that this is the case is there even a need to check for these
>>> libraries? Or is this test needed for Cygwin or minGW builds?
>>>
>>
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it.  On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that.  So before making any decisions here, I think
>> we need to collect more information.  For example, I would like you to
>> try 3.9.4 (see other thread concerning CMake versions) to see if this
>> particular problem persists (and also to determine whether CMake-3.9.4
>> satisfies all PLplot build-system needs for your Windows SDK version.)
>>
>>
>> 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).
>> __
>>
>> 

Re: [Plplot-devel] wingcc and wingdi build bugs

[Jim Dishaw]

I think that is a Windows vs Windows 8. I will look at that today and patch. 

> On Dec 31, 2017, at 1:10 AM, Greg Jung  wrote:
> 
> Hi guys,
>Because my main PC (win 7) is busted I am working with a backup system 
> which is windows 8.1 pro 32-bits
> and I was interested in deploying the new wingdi for GDL on windows.  
> Although no errors were anticipated from the
>  cmake processing (required setting  PLD_wingdi=ON) the build came up short 
> finding a library:
>>> Scanning dependencies of target wingdi
>>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>>> [ 67%] Linking C shared module ../dll/wingdi.dll
>>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7): 
>>> undefined reference to `_imp__InitCommonControlsEx@4'
>>> collect2.exe: error: ld returned 1 exit status
>>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104: dll/wingdi.dll] 
>>> Error 1
>>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all] 
>>> Error 2
>>> make: *** [Makefile:152: all] Error 2
> 
> I also found, although it isn't important for me downstream, that my QHULL 
> installation was not found correctly. I checked where they were to be found, 
> here is a partial listing of that:
>>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>>> %FILES%
>>> mingw32/
>>> mingw32/bin/
>>> mingw32/bin/qconvex.exe
>>> mingw32/bin/qdelaunay.exe
>>> mingw32/bin/qhalf.exe
>>> mingw32/bin/qhull.exe
>>> mingw32/bin/qvoronoi.exe
>>> mingw32/bin/rbox.exe
>>> mingw32/include/
>>> mingw32/include/qhull/
>>> mingw32/include/qhull/geom.h
>>> mingw32/include/qhull/libqhull.h
>> 
> 
> 
>> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin  
>> wrote:
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>> 
>>> Given that the libraries in question are in the standard c and C++
>>> libraries. I just tested to see what the impact is of simply
>>> commenting out the checks for these two libraries.
>>> 
>>> The result is that wingcc is accepted onto the driver list, appears in
>>> my plplot VC++ project, everything builds correctly and I can run the
>>> examples and select the wingcc device and everything runs fine.
>>> 
>>> Given that this is the case is there even a need to check for these
>>> libraries? Or is this test needed for Cygwin or minGW builds?
>> 
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it.  On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that.  So before making any decisions here, I think
>> we need to collect more information.  For example, I would like you to
>> try 3.9.4 (see other thread concerning CMake versions) to see if this
>> particular problem persists (and also to determine whether CMake-3.9.4
>> satisfies all PLplot build-system needs for your Windows SDK version.)
>> 
>> 
>> Alan
>> __
>> Alan W. Irwin
>> 
>> Astronomical research affiliation with Department of Physics and Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>> 
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __
>> 
>> Linux-powered Science
>> __
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Plplot-devel mailing list
>> Plplot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Greg Jung]

Hi guys,
   Because my main PC (win 7) is busted I am working with a backup system
which is windows 8.1 pro 32-bits
and I was interested in deploying the new wingdi for GDL on windows.
Although no errors were anticipated from the
 cmake processing (required setting  PLD_wingdi=ON) the build came up short
finding a library:

> Scanning dependencies of target wingdi
>
> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>
> [ 67%] Linking C shared module ../dll/wingdi.dll
>
> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7):
>> undefined reference to `_imp__InitCommonControlsEx@4'
>
> collect2.exe: error: ld returned 1 exit status
>
> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104:
>> dll/wingdi.dll] Error 1
>
> make[1]: *** [CMakeFiles/Makefile2:1263:
>> drivers/CMakeFiles/wingdi.dir/all] Error 2
>
> make: *** [Makefile:152: all] Error 2
>
>
I also found, although it isn't important for me downstream, that my QHULL
installation was not found correctly. I checked where they were to be
found, here is a partial listing of that:

> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>
> %FILES%
>
> mingw32/
>
> mingw32/bin/
>
> mingw32/bin/qconvex.exe
>
> mingw32/bin/qdelaunay.exe
>
> mingw32/bin/qhalf.exe
>
> mingw32/bin/qhull.exe
>
> mingw32/bin/qvoronoi.exe
>
> mingw32/bin/rbox.exe
>
> mingw32/include/
>
> mingw32/include/qhull/
>
> mingw32/include/qhull/geom.h
>
> mingw32/include/qhull/libqhull.h
>
>
>
On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin 
wrote:

> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>
> Given that the libraries in question are in the standard c and C++
>> libraries. I just tested to see what the impact is of simply
>> commenting out the checks for these two libraries.
>>
>> The result is that wingcc is accepted onto the driver list, appears in
>> my plplot VC++ project, everything builds correctly and I can run the
>> examples and select the wingcc device and everything runs fine.
>>
>> Given that this is the case is there even a need to check for these
>> libraries? Or is this test needed for Cygwin or minGW builds?
>>
>
> The present library finding has "just worked" for a long time for a
> large variety of Windows users on many different Windows platforms so
> I am somewhat reluctant to change it.  On the other hand, I guess it
> is possible if you don't need it, then nobody needs it, but I am not
> at all sure about that.  So before making any decisions here, I think
> we need to collect more information.  For example, I would like you to
> try 3.9.4 (see other thread concerning CMake versions) to see if this
> particular problem persists (and also to determine whether CMake-3.9.4
> satisfies all PLplot build-system needs for your Windows SDK version.)
>
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Alan W. Irwin]

On 2017-10-06 11:00+0100 Phil Rosenberg wrote:


Given that the libraries in question are in the standard c and C++
libraries. I just tested to see what the impact is of simply
commenting out the checks for these two libraries.

The result is that wingcc is accepted onto the driver list, appears in
my plplot VC++ project, everything builds correctly and I can run the
examples and select the wingcc device and everything runs fine.

Given that this is the case is there even a need to check for these
libraries? Or is this test needed for Cygwin or minGW builds?


The present library finding has "just worked" for a long time for a
large variety of Windows users on many different Windows platforms so
I am somewhat reluctant to change it.  On the other hand, I guess it
is possible if you don't need it, then nobody needs it, but I am not
at all sure about that.  So before making any decisions here, I think
we need to collect more information.  For example, I would like you to
try 3.9.4 (see other thread concerning CMake versions) to see if this
particular problem persists (and also to determine whether CMake-3.9.4
satisfies all PLplot build-system needs for your Windows SDK version.)

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Phil Rosenberg]

Given that the libraries in question are in the standard c and C++
libraries. I just tested to see what the impact is of simply
commenting out the checks for these two libraries.

The result is that wingcc is accepted onto the driver list, appears in
my plplot VC++ project, everything builds correctly and I can run the
examples and select the wingcc device and everything runs fine.

Given that this is the case is there even a need to check for these
libraries? Or is this test needed for Cygwin or minGW builds?

I also did a quick google and spotted this bug report
https://cmake.org/Bug/view.php?id=15831. I think the gist of it is
that find_library will only search in Windows SDKs that are at least
as old as the one used to build that version of Cmake. This seems a
bit daft to me as it forces upgrade whenever a new SDK is released - I
know in the past Alan has mentioned the need to not upgrade due to a
bug in a release, but that may not be an option if this is the case.
Again maybe this suggests that we should simply not use find_library
and simply assume that these libraries will be included in with the
standard libraries.

Phil

On 5 October 2017 at 22:42, Alan W. Irwin  wrote:
> On 2017-10-05 09:10+0100 Phil Rosenberg wrote:
>
>> On 5 October 2017 at 04:10, Alan W. Irwin 
>> wrote:
>>>
>>> The cmake messages above come from cmake/modules/wingcc.cmake and the
>>> first part of the relevant logic is
>>>
>>>   find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH}
>>> ${BORLANDLIBPATH})
>>>   if(GDI32_LIBRARY)
>>>   find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
>>> ${BORLANDLIBPATH})
>>>   endif(GDI32_LIBRARY)
>>>
>
>> gdi32.dll and comdlg32 are both in the standard system directory
>> c:/windows/system32/
>
>
>>> If both those libraries are installed on your system but in a
>>> non-standard location that CMake doesn't know about, then
>>> you may have to give CMake a hint where they are by setting
>>> CMAKE_LIBRARY_PATH appropriately.
>
>
> Hi Phil:
>
> One thing I noticed from your previous post that included all the
> information from cmake was your cmake version was 3.7.1. My impression
> is there has been a lot of churn in the various Windows IDE generators
> since 3.7.1 due to lots of bug fixing so this issue might be solved
> simply by downloading and using the latest binary version of CMake
> (3.9.4) directly from Kitware.
>
> But if you would prefer to stick to 3.7.1 for now or if 3.9.4 still
> has the same symptoms, then from the above collection of information I
> suggest you add c:/windows/system32/ to the CMAKE_LIBRARY_PATH
> information you already have (on Linux the format is a colon-separated
> list of library locations, but on Windows that may be a
> semicolon-separated list), and I am virtually positive that will solve
> the library finding issue for wingcc.  And if you set -DPLD_wingdi=ON,
> it should also solve it for wingdi (since that device uses the same
> libraries and same library finding logic as wingcc).
>
> By the way I am virtually positive that if CMake cannot find these
> standard system libraries in one of the expected standard locations
> without user help via CMAKE_LIBRARY_PATH, then that is a clear CMake
> bug (likely for the particular generator you are using). So if you
> confirm that this bug still persists with 3.9.4 directly downloaded
> from Kitware, then to help other users in your position, I plan to
> follow up with the CMake developers about this bug, but before
> starting that discussion I will need to know the exact
> generator you are using for your Windows IDE.
>
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Alan W. Irwin]

On 2017-10-05 09:10+0100 Phil Rosenberg wrote:


On 5 October 2017 at 04:10, Alan W. Irwin  wrote:

The cmake messages above come from cmake/modules/wingcc.cmake and the
first part of the relevant logic is

  find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
  if(GDI32_LIBRARY)
  find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
${BORLANDLIBPATH})
  endif(GDI32_LIBRARY)




gdi32.dll and comdlg32 are both in the standard system directory
c:/windows/system32/



If both those libraries are installed on your system but in a
non-standard location that CMake doesn't know about, then
you may have to give CMake a hint where they are by setting
CMAKE_LIBRARY_PATH appropriately.


Hi Phil:

One thing I noticed from your previous post that included all the
information from cmake was your cmake version was 3.7.1. My impression
is there has been a lot of churn in the various Windows IDE generators
since 3.7.1 due to lots of bug fixing so this issue might be solved
simply by downloading and using the latest binary version of CMake
(3.9.4) directly from Kitware.

But if you would prefer to stick to 3.7.1 for now or if 3.9.4 still
has the same symptoms, then from the above collection of information I
suggest you add c:/windows/system32/ to the CMAKE_LIBRARY_PATH
information you already have (on Linux the format is a colon-separated
list of library locations, but on Windows that may be a
semicolon-separated list), and I am virtually positive that will solve
the library finding issue for wingcc.  And if you set -DPLD_wingdi=ON,
it should also solve it for wingdi (since that device uses the same
libraries and same library finding logic as wingcc).

By the way I am virtually positive that if CMake cannot find these
standard system libraries in one of the expected standard locations
without user help via CMAKE_LIBRARY_PATH, then that is a clear CMake
bug (likely for the particular generator you are using). So if you
confirm that this bug still persists with 3.9.4 directly downloaded
from Kitware, then to help other users in your position, I plan to
follow up with the CMake developers about this bug, but before
starting that discussion I will need to know the exact
generator you are using for your Windows IDE.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Phil Rosenberg]

On 5 October 2017 at 04:10, Alan W. Irwin  wrote:
> On 2017-10-05 00:57+0100 Phil Rosenberg wrote:
>
>> The my cmake command and its output are attached. I noted particularly the
>> lines
>>
>> -- Looking for gdi32 header and library
>> -- Looking for gdi32 header and library - not found
>> -- WARNING: Setting PLD_wingcc to OFF.
>>
>
>> I do set the cmake lib directory in my command to point it to the
>> location of shapelib, I don't know if that affects anything.
>
>
> Setting CMAKE_LIBRARY_PATH to help CMake find shapelib should not
> interfere with CMake's ability to find other libraries.
>
>> I am on Windows 10 64 bit.
>
>
> Thanks for that important information concerning your Windows version.
>
> The cmake messages above come from cmake/modules/wingcc.cmake and the
> first part of the relevant logic is
>
>   find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   if(GDI32_LIBRARY)
>   find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
> ${BORLANDLIBPATH})
>   endif(GDI32_LIBRARY)
>
> If you read through the rest of the logic, the above output is telling
> you that either the gdi32 (gdi) or comdlg32 (dialog box) libraries
> cannot be found by CMake in standard system locations (as determined
> by CMake) for your platform.
>
> What does your cache file say about the variables GDI32_LIBRARY and
> (possibly) COMDLG32_LIBRARY?  From those values you can determine
> whether gdi32 was not found (and therefore comdlg32 never looked for)
> or gdi32 found but comdlg32 not found.

//Path to a library.
GDI32_LIBRARY:FILEPATH=GDI32_LIBRARY-NOTFOUND

There is no similar line for comdlg32.

However, both these libraries feature in the standard libraries

//Libraries linked by default with all C++ applications.
CMAKE_CXX_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib
advapi32.lib

//Libraries linked by default with all C applications.
CMAKE_C_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib
advapi32.lib

gdi32.dll and comdlg32 are both in the standard system directory
c:/windows/system32/

Dependency walker also shows that wxPLViewer uses both of them.



>
> If both those libraries are installed on your system but in a
> non-standard location that CMake doesn't know about, then
> you may have to give CMake a hint where they are by setting
> CMAKE_LIBRARY_PATH appropriately.
>
> However, I suspect instead the problem may be that the GDI API and
> Dialog Box API (which apparently are still used heavily on all Windows
> platforms
> including Windows 10) are located in libraries with names other than
> gdi32 and comdlg32 for your 64-bit Windows 10 platform.  If so, and
> you know those alternate names, then all you have to do is to change
> the above logic to
>
>   find_library(GDI32_LIBRARY NAMES gdi32  HINTS
> ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   if(GDI32_LIBRARY)
>   find_library(COMDLG32_LIBRARY NAMES comdlg32  comdlg32> HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
>   endif(GDI32_LIBRARY)
>
> @Arjen and Jim:
>
> Please chime in as well especially on the question of what library
> names provide the GDI API and Dialog Box API for the 64-bit Windows 10
> platform if Phil doesn't figure those names out before you.
>
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Arjen Markus]

Hi Alan,



My system is Windows 7 and I do not have easy access to a Windows 10 machine 
with a suitable development environment. Perhaps there are release notes at 
MSDN that can shed some light on the matter?



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, October 05, 2017 5:10 AM
> To: Phil Rosenberg; Jim Dishaw; Arjen Markus; PLplot development list
> Subject: Re: wingcc and wingdi build bugs
>
> On 2017-10-05 00:57+0100 Phil Rosenberg wrote:
>
> > The my cmake command and its output are attached. I noted particularly
> > the lines
> >
> > -- Looking for gdi32 header and library
> > -- Looking for gdi32 header and library - not found
> > -- WARNING: Setting PLD_wingcc to OFF.
> >
>
> > I do set the cmake lib directory in my command to point it to the
> > location of shapelib, I don't know if that affects anything.
>
> Setting CMAKE_LIBRARY_PATH to help CMake find shapelib should not interfere
> with CMake's ability to find other libraries.
>
> > I am on Windows 10 64 bit.
>
> Thanks for that important information concerning your Windows version.
>
> The cmake messages above come from cmake/modules/wingcc.cmake and the
> first part of the relevant logic is
>
>find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH}
> ${BORLANDLIBPATH})
>if(GDI32_LIBRARY)
>find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
> ${BORLANDLIBPATH})
>endif(GDI32_LIBRARY)
>
> If you read through the rest of the logic, the above output is telling you 
> that either
> the gdi32 (gdi) or comdlg32 (dialog box) libraries cannot be found by CMake in
> standard system locations (as determined by CMake) for your platform.
>
> What does your cache file say about the variables GDI32_LIBRARY and
> (possibly) COMDLG32_LIBRARY?  From those values you can determine whether
> gdi32 was not found (and therefore comdlg32 never looked for) or gdi32 found 
> but
> comdlg32 not found.
>
> If both those libraries are installed on your system but in a non-standard 
> location
> that CMake doesn't know about, then you may have to give CMake a hint where
> they are by setting CMAKE_LIBRARY_PATH appropriately.
>
> However, I suspect instead the problem may be that the GDI API and Dialog Box
> API (which apparently are still used heavily on all Windows platforms 
> including
> Windows 10) are located in libraries with names other than
> gdi32 and comdlg32 for your 64-bit Windows 10 platform.  If so, and you know
> those alternate names, then all you have to do is to change the above logic to
>
>find_library(GDI32_LIBRARY NAMES gdi32  HINTS
> ${MINGWLIBPATH} ${BORLANDLIBPATH})
>if(GDI32_LIBRARY)
>find_library(COMDLG32_LIBRARY NAMES comdlg32  comdlg32> HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
>endif(GDI32_LIBRARY)
>
> @Arjen and Jim:
>
> Please chime in as well especially on the question of what library names 
> provide the
> GDI API and Dialog Box API for the 64-bit Windows 10 platform if Phil doesn't
> figure those names out before you.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project 
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi 
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the 
> Linux
> Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] wingcc and wingdi build bugs

[Jim Dishaw]

> On Oct 4, 2017, at 3:26 PM, Alan W. Irwin  wrote:
> 
> To Phil, Jim, and Arjen:
> 
>> On 2017-10-04 12:11+0100 Phil Rosenberg wrote:
>> 
>> For some reason I cannot build wingcc or wingdi, they do not come up
>> as enabled on my system when I run cmake. I have never looked into why
>> as I don't use them.
> 
> But all members of the PLplot development team should be concerned if
> wingcc (a workhorse interactive device that has been around a long
> time and which presumably builds on most Windows platforms) does not
> build on your particular Windows platform.  Because other users also
> have that same platform, and they may need access to wingcc (and
> wingdi).  So please follow up with a complete bug report here
> (preferably) or on the bug tracker including all relevant information
> about your Windows platform and the exact build error.  And similarly
> for the wingdi case (although that has not been around as long as
> wingcc it is based on it so it may have a common build problem on your
> particular Windows platform).  Arjen or Jim (both with a lot
> of Windows experience) might be able to quickly resolve the issue
> you are encountering.
> 
> You might also want to look at
> https://sourceforge.net/p/plplot/support-requests/44/
> (which is in the support-request category, but it is really
> a bug report).  That user was having trouble building wingdi
> on "Cygwin 64 (CYGWIN_NT-10.0) on Winows 10 (64-bit)".  But for
> that same platform he built wingcc with no issues.
> 
> @Jim:
> 
> You obviously had a lot of discussion with this user concerning his
> wingdi build bug including sending him patches to try, but it seemed
> to trail off at the end with nothing resolved with regard to the
> wingdi build bug on his platform.  What needs to be done to get this
> issue resolved?
> 

He was able to get the release to build according to his last message. I still 
need to work on the wingdi build for the environments that do not have the 
newer windows api calls. I need to spinup a VM running an older version of 
Windows to test. 

As for the big, that has to do with the pause mechanism and I have been waiting 
for the wxwidgets driver to stabilize. I’m going to make wingdi have the same 
behavior as wxwidgets relative to the pause. 

> Alan
> __
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
> 
> Linux-powered Science
> __


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] wingcc and wingdi build bugs

[Alan W. Irwin]

To Phil, Jim, and Arjen:

On 2017-10-04 12:11+0100 Phil Rosenberg wrote:


For some reason I cannot build wingcc or wingdi, they do not come up
as enabled on my system when I run cmake. I have never looked into why
as I don't use them.


But all members of the PLplot development team should be concerned if
wingcc (a workhorse interactive device that has been around a long
time and which presumably builds on most Windows platforms) does not
build on your particular Windows platform.  Because other users also
have that same platform, and they may need access to wingcc (and
wingdi).  So please follow up with a complete bug report here
(preferably) or on the bug tracker including all relevant information
about your Windows platform and the exact build error.  And similarly
for the wingdi case (although that has not been around as long as
wingcc it is based on it so it may have a common build problem on your
particular Windows platform).  Arjen or Jim (both with a lot
of Windows experience) might be able to quickly resolve the issue
you are encountering.

You might also want to look at
https://sourceforge.net/p/plplot/support-requests/44/
(which is in the support-request category, but it is really
a bug report).  That user was having trouble building wingdi
on "Cygwin 64 (CYGWIN_NT-10.0) on Winows 10 (64-bit)".  But for
that same platform he built wingcc with no issues.

@Jim:

You obviously had a lot of discussion with this user concerning his
wingdi build bug including sending him patches to try, but it seemed
to trail off at the end with nothing resolved with regard to the
wingdi build bug on his platform.  What needs to be done to get this
issue resolved?

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel