Hi Arjen,
>
> I have been trying to get PLplot to build under MSYS on Windows
> (FYI: MSYS is the Linux/UNIX-like environment for MinGW), but
> so far I have failed. The reason is that CMake picks up the
> MS Visual C/C++ import libraries for the system libraries gdi32.dll
> and comgdi32.dll.
>
> Here is my analysis:
>
> - The variable MSYS should be set to 1 (true) if CMake is running
>   under MSYS, but it is not. MinGW is set to true.
>   So I now check that the environment variable OSTYPE is set to
>   "msys" to detect if it is running under MSYS.

MINGW is set to TRUE since MSys is only an environment which uses the  
MinGW compiler. MSYS must be set to true as well (look at the end of  
the cmake configuration stage output - I added MSYS and MINGW to  
summary.cmake already some years ago).

>
> - In wingcc.cmake, we have code to look for the gdi32 and comgdi32
>   libraries via find_library and useful hints via MINGWLIBPATH.
>   So to support MSYS, I set MINGWLIBPATH to the correct MSYS library
>   path (merely extending the condition in plplot.cmake)

I made this changes to wingcc.make so that we reduce cmake warnings.  
Earlier we tested if a program which uses gdi32 can be compiled, so  
then we added -lgdi32. But cmake would then complain that we use a  
library without full path. I changed then the logic

* in plplot/CMakeLists.txt I added some compiler specific stuff for  
MinGW and Borland compiler. It mainly sets MINGWLIBPATH and  
BORLANDLIBATH (line 48).
* in wingcc.cmake I use find_library() to determine the library paths  
using the variables above as HINTS. Otherwise find_library would find  
the gdi32.dll in the system path first and use that since MinGW linker  
is able to link directly against dlls (no import library needed). The  
only way to use find_library is to tell the function explicitly where  
the library is.

So you would need to find out where the gdi32.lib file is for MSYS and  
add something like that what I did in plplot/CMakeLists.txt. You  
if(MSYS)/endif(MSYS) clause must be inside the if(MINGW)/endif(MINGW)  
clause since AFAIK is MINGW and MSYS true for the MSys environment.  
Then you add ${MSYSLIBPATH} at the right place in wingcc.cmake or you  
set ${MINGWLIBPATH) anyways.

>
> - The effect of these changes is strange though:
>   - The build scripts seem to be set up for building PLplot as
>     static libraries with static drivers (everything is concentrated
>     in the src subdirectory
>   - The build.cmake file contains dependencies to the MSVC import
>     libraries (gdi32.lib and comgdi32.lib), not to the MSYS libraries
>     (libgdi32.a and libcomgdi32.a).

The latter one is due find_library finds the MSVC libraries first. The  
first effect I can't explain?
>
> The reason for this may be that CMake on Windows does not recognise
> the libxxx.a pattern for libraries. A workaround is to force these
> libraries to be used, but perhaps there is a better way?
>
> The first effect, however, is more worrisome. My guess is that we
> do not yet have propagated all build options for this platform.
> I will try to sort this one out in the coming days.

If you need further help let me know.

Regards,
Werner
>
> Regards,
>
> Arjen
>
>
> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of  
> TNO and parts of Rijkswaterstaat have joined forces in a new  
> independent institute for delta technology, Deltares. Deltares  
> combines knowledge and experience in the field of water, soil and  
> the subsurface. We provide innovative solutions to make living in  
> deltas, coastal areas and river basins safe, clean and sustainable.
>
>
>
> 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.
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Plplot-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: [email protected]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to