HOWTO : build GDL on windows

2012-10-04
2015-04-09
  • Jeongbin Park
    Jeongbin Park
    2012-10-04

    You can read from here.

    I tried to post it here, but it says that it looks like a spam… It would be nice if there were a wiki !

     
    • GregJung
      GregJung
      2015-01-28

      Building GDL has become quite easy since using msys2

      Skim through the painful attempts to build the libraries piece-by-piece.
      msys2 project has most all required libraries pre-built.

       
  • GregJung
    GregJung
    2014-05-01

    Most of my earlier troubles derived from incorrect header sets.

    ignorance cured, post deleted

    The lingering problem was that
    cmake -G "MSYS Makefiles" ../
    didn't operate very smooothly, see previous post for the mods I made so that it does.

    fyi here is how my shell is set up:
    was:
    export "CFLAGS=-I/usr/local/include -I/mingw/include -march=i686"
    export "CXXFLAGS=-I/usr/local/include -I/mingw/include"
    export "LDFLAGS=-L/usr/local/lib -L/mingw/lib"
    export "PKG_CONFIG_PATH=/usr/local/lib/pkgconfig"

    export CC="gcc -O2"
    export CXX="g++ -O2"
    export FC="gfortran -O2"

    MSYS sends a "translated" environment to cmake when it requests, i.e., $ENV{LDFLAGS}. In the case above, the answer would look like "D:/mingw/msys/1.0/local/lib -L/mingw/lib" but if you tried to fix it
    by D:/mingw/lib you get a worse mess. My mods deal with this as well as
    for the pkg-config requirements, if there are more than one PKG_CONFIG_PATH(s).

    now:
    export "CFLAGS=-I/usr/local/include -I/mingw/include"
    export "CXXFLAGS=-I/usr/local/include -I/mingw/include"
    export "LDFLAGS=-L/usr/local/lib -L/mingw/lib"
    export "PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/mingw/lib/pkgconfig"
    
    export CC="gcc -O2 -mms-bitfields -mthreads -mtune=pentium3"
    export CXX="g++ -O2 -mms-bitfields -mthreads -mtune=pentium3"
    export FC="gfortran -O2 -mms-bitfields"
    
     
    Last edit: GregJung 2014-06-05
    • GregJung
      GregJung
      2014-05-07

      I (may have) fixed most of my problems by fixing my /mingw installation. I have to take a pause, though, because of this notice included in gcc-4.7.2-ming32.README:

      Binary incompatibility notice!


      ==========================================================

      (note June 2014)Evidently everything is copascetic.

       
      Last edit: GregJung 2014-06-05
  • GregJung
    GregJung
    2014-06-05

    plplot - the continuing saga

    After getting gdl/cmake satisfied up to the optional libraries, I'm gonna return to PLPLOT building. Last time it "built" but the tests didn't plot anything. I'm adding PSLIB (version 0.4.5) which then needs to use inttool which then needs a working perl with XML::Parser module so I have to learn all that ... msys-perl as it came from mingw-get
    didn't have a module library but i found another
    http://lrn.no-ip.info/other/mingw/msys/perl/5.8.8-0RC1/perl-5.8.8-1-msys-1.0.16-bin.tar.lzma
    which had it all. Then XML::Parser package has to be perl'd, ..

     
    • giloo
      giloo
      2014-06-05

      Hi,
      For what it is worth, my advice:
      plplot: evidently if their test plots do not work, you'll have no chance for plots in GDL. There seem to be a lot of activity in the plplot mailing list plplot-devel@lists.sourceforge.net about window support, perhaps some information there?
      PSLIB: is not really needed (plplot makes correct eps files for gdl).

       
  • GregJung
    GregJung
    2014-06-15

    I've now built PLPLOT in mingw/msys, using freetype (after my modifications to CMAKE scripts), I had to push things along to complete it. The header files that were generated, and a few more from /lib directory, are not found for the compile; I had to copy the necessary files into the main /include directory - as if only a single directory ${CMAKE_SOURCE_DIR}/include is communicated to the make files.
    wingcc.c had further issues with freetype headers: I hand-compiled the module with the -I{..}/include/freetype2 on the command line (where ft2build.h was located). Installations where ft2build.h is found in the common include directories should have an easier time of it.
    6-15-2014
    =====================
    7-3-2014
    re-edit: I've resolved the issue where freetype-needy modules didn't
    get proper include-directory command lines. In my particular freetype
    version the directory include/freetype2 need be in the gcc line so that
    include/ft2build.h can find ftheader.h ... anyway, the plplot-5.10.0
    still calls out for FREETYPE_INCLUDE_DIR which isn't set even in the latest cmake version of FindFreetype, or for the package-find solution
    FREETYPE_INCLUDE_DIRS is set not the singular. This is changed in the upcoming plplot build, since 3/2014 (#13025), by copying include_dirs to a new variable FREETYPE_INCLUDE_CFLAGS in the custom freetype.cmake routine.
    src/CMakelists.txt, cmake/modules/wingcc.cmake, wxwidgets.cmake
    =====
    Now on to testing plplot under windows ...
    =====================
    April 2015
    All that stuff about freetype is interesting, but unecessary.
    GDL doesn't use the freetype capacities of the plplot drivers.
    There is a lot of "#ifdef nolise in the windows driver wingcc.c
    about this but it doesnt matter.

     
    Last edit: GregJung 2015-04-09
  • Alain C.
    Alain C.
    2014-06-28

    My student Loria, with the help of Jeongbin Park during GDL workshop,
    learn how to compile on MS-windows within MinGW.

    He also prepared a document
    http://aramis.obspm.fr/~coulais/IDL_et_GDL/HowTo_Compile_GDL_on_MinGW.html

    HTH

    comments, suggestions, extension very welcome !

    Alain

     
    • GregJung
      GregJung
      2014-07-04

      How is the performance of your build? Do you find the same problems as in this review?
      https://sourceforge.net/projects/gnudatalanguage-win32/reviews?source=navbar
      ( the plot window was very buggy).
      Perhaps there was some 64-bit stuff mixed in, it was that bad. One thing happened though, somehow running the GDL healed my initial lack
      of plplot definitions (once I copied a few dlls into the /bin directory).

       
  • Alain C.
    Alain C.
    2014-06-28

    I forgot to mention we did not really tested the performance with the Eigen part, which need also OpenMP to be efficient on multicore ...

    Next step here will be to have OpenMP in MSwin !

    Alain

     
    • GregJung
      GregJung
      2015-04-09

      I have been tracking a nasty bug (a simple arithmetic statement sank the program) that I found was coincident with using EIGEN. Its only recently that this happened so its possible the distributed msys2/mingw32/ eigen package has the real problem.

      In any case, when eigen is invoked the entire build tree is affected

      includefirst.hpp
      
      #if defined(USE_EIGEN)
      #include <Eigen/Core>
      #endif
      
       
      Last edit: GregJung 2015-04-12
  • GregJung
    GregJung
    2015-01-28

    Using msys2

    A more proper designation for msys2 is mingw-w64/msys2 in analogy with
    mingw/msys. The installation leaves one with a shell more closely behaving as the cygwin shell. Three modes of running the (almost completely) bash shell: MSYS, MINGW32, and MINGW64. They differ, via the batch shells that launch them, mainly via the paths they employ.

    See installation instructions via the MSYS2 Wiki http://sourceforge.net/p/msys2/wiki/Home/. You may also want to find the pages for pacman, from arch linux, as this is the package manager msys2 uses.
    https://wiki.archlinux.org/index.php/Pacman_tips

    Any GCC compilation will have made a choice of two threading systems, and for C++, two exception handling protocols. Mixing these up is permissible in link, but it can lead to a messy configuration downstream. In particular, the ilbstdc++ library comes in two flavors for any given bited-ness, and it includes threading routines. The thread/exception pair of a gcc compiler can be seen in the output of "gcc -v". When a compiler is packaged from mingw-w64, it is generally built in four different combinations each for 32- and for 64- bit builds. Happily for mingw/msys2 then you dont have to choose - it is chosen to be posix threads, dwarf2 exception for i686 (32- bit) and posix-thread, seh exception for (64-bit) x86_64. Compilers I have from mingw.org (for msys1) are win32 threads and sjlj or seh exceptions, although I presume any of these could be swapped for another.

    To reassure myself of the origins of the various libraries I might build, I install any given distribution under its own name, those under
    names such as mingw32/psxdw2, mingw32/winsjlj etc. then copies are made to put them in consolidated directories where they are accessed
    named such as opt32-psxdw2 and opt64-psxseh for 64-bit. In the
    msys2 root directory I make an NTFS directory symlink to these consolidated collections.

    When I run a GDL built this way I generally have to move out of the MSYS2 shell to a more genuinely microsoft terminal emulator. So I have to set my path up to include the shareable images needed. For a distribution in windows, all of the support should just be thrown together where the program is executed from. If they are not there then the PATH needs to be set to get them.

    To facilitate posix-like behavior in the spawned processes I run
    GDL from a win-bash shell sittig on top of the command shell CMD.exe.
    C:\usr\bin contains utilities in support of the shell and the NTDOS
    shell itself points to its own set of .bat files. If I am to run 32-bit GDL then from the NT shell I execute reset32.bat which set the path
    for that. I then execute bash and it will look "kinda" like a posix shell (but still have terminal properties). Besides the mingw32/bin
    directory for the installed mingw32 shareable support libraries, there
    are two other directories to put these, before and after the entry for mingw32/bin.

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    D:\cmd>reset32
    
    D:\cmd>path
    PATH=C:\cmd;C:\cmd/bin;C:\usr/bin;
        C:\usr/bin32;C:\usr/bin32/mingw;C:\usr/lib32;
       C:\Windows/system32;C:\Windows;C:\Windows/System32/Wbem
    
    D:\cmd>C:
    
    C:\>cd usr/bin32
    
    C:\usr\bin32>dir
     Volume in drive C is HomerW7
     Volume Serial Number is 6828-F366
    
     Directory of C:\usr\bin32
    
    07/17/2015  10:24 PM    <DIR>          .
    07/17/2015  10:24 PM    <DIR>          ..
    04/21/2015  03:03 PM        13,113,045 gdl.exe
    04/24/2015  05:27 PM           119,070 libcsirocsa.dll
    04/05/2015  10:28 PM           203,638 libcsironn.dll
    06/24/2015  07:52 PM           190,122 libplplotcxxgdl11nd.dll
    06/24/2015  07:52 PM           840,560 libplplotgdl11nd.dll
    06/24/2015  07:52 PM            90,960 libplplotwxwidgetsgdl11nd.dll
    04/24/2015  05:27 PM           120,904 libqsastime.dll
    03/07/2015  08:51 PM    
              <JUNCTION>     mingw [c:\msys64\mingw32\bin]
    07/17/2015  10:24 PM 
              <SYMLINK>      python [c:\msys64\mingw32\bin\python.exe]
    04/21/2015  11:51 AM               241 reset64.bat
    04/21/2015  03:07 PM        47,972,989 wxbase30u_gcc_gdl.dll
    04/21/2015  03:07 PM        21,605,181 wxmsw30u_adv_gcc_gdl.dll
    04/21/2015  03:07 PM       183,117,060 wxmsw30u_core_gcc_gdl.dll
                  12 File(s)    267,373,770 bytes
                   3 Dir(s)  29,138,956,288 bytes free
    
    C:\usr\bin32>bash
     C:/Users/greg/.bashrc invoked
     --->> Note <<---
     This is win-bash designed to bring a little
     unix comfort to the NT DOS shell. 
    It is supported with utils in C:\usr/ <<
    
    bash$ echo $PATH
    C:\cmd:C:\cmd/bin:C:\usr/bin:
        C:\usr/bin32:C:\usr/bin32/mingw:C:\usr/lib32:
      C:\Windows/system32:C:\Windows:C:\Windows/System32/Wbem
    bash$ alias
    alias gdl11='d:/bld/gdl/mingw32-plplot11/src/gdl'
    alias gdl32='d:/bld/gdl32/bin/gdl'
    alias gdl64='d:/bld/gdl64/bin/gdl'
    alias gdlcvs='d:/bld/gdl32/cvs/bin/gdl'
    alias gdlf32='f:/gdl/mingw32/src/gdl.exe'
    alias gdlgdi='d:/bld/gdl64/gdl_plplotgdl11gdi.exe'
    alias gdlnew='d:/bld/gdl/mingw32new/src/gdl'
    alias gdltst32='d:/bld/gdl/mingw32/src/gdl'
    alias gdltst64='d:/bld/gdl/mingw64/src/gdl'
    
     
    Last edit: GregJung 2015-07-21
  • GregJung
    GregJung
    2015-01-29

    MINGW file organisations:

    Mingw.org installation installs mingw then MSYS is an optional addition.
    Installation might look like the following

    C:/Mingw/
        bin/
        mingw32/
        include/
        lib/
        msys/
          msys/1.0/
                /bin/
                /lib/
                /local/
                /include/
                /msys.bat
        share/
    

    Where, the MSYS shell is begun with msys.bat. Already mounted are "/" and "/usr"
    pointing to .../msys/1.0/. Working and tested support libraries were put in mingw/lib. The GCC toolchain is found under /mingw32 mostly, lately, but there are significant-looking files elsewhere such as libexec/gcc/. include/ seems to be repository for the files you would include, but gcc will first look in its own set.
    AFAIK there is no documentation about what goes where.

    MSYS2 installation starts with C:/MSYS64 or C:/MSYS32 which is where "/" is mounted.

     C:/msys64/
        bin/
        mingw32/
        mingw64/
        mingw32_shell.bat
        mingw64_shell.bat
        msys2_shell.bat
        var/
        usr/
           bin/
           etc/
           lib/
           libexec/
           local/
    

    MSYS2 uses pacman to install the libraries and toolset packages and to track which files come from which package. After the base MSYS2 packages are installed, MINGW packages are brought in beginning with the GCC compiler suite, under /mingw64. pre-built libraries of several topics can also be loaded with pacman, they also will reside in /mingw64.

     
  • GregJung
    GregJung
    2015-01-29

    Downloading support libraries: I was already building 64-b it GDL with msys2, now for 32-bit builds I use same msys64/. Here are the installation commands I use to get near satisfying all of GDL required libraries: I load wxWidgets early since that wil bring in many lower-level libraries.

    pacman -S mingw32/mingw-w64-i686-zlib
    pacman -S mingw32/mingw-w64-i686-wxWidgets
    pacman -S mingw32/mingw-w64-i686-fftw
    pacman -S mingw32/mingw-w64-i686-gsl
    pacman -S mingw32/mingw-w64-i686-readline
    pacman -S mingw32/mingw-w64-i686-ncurses-5.9.2
    pacman -S mingw32/mingw-w64-i686-glib2
    pacman -S mingw32/mingw-w64-i686-graphicsmagick
    pacman -S mingw32/mingw-w64-i686-pango
    pacman -S mingw32/mingw-w64-i686-proj
    pacman -S mingw32/mingw-w64-i686-gcc
    

    with this download I was able to compile plplot on first try! (I already had it set up to compile). You can also simply download the stock plplot using pacman, with some extra baggage (python, ada, tcl/tk) and plplot-5.10 library files will be there for you. Do not download portable-xdr, this is not the xdr version that GDL uses. Instead, install
    BSD-xdr https://code.google.com/p/bsd-xdr/
    1. unpack bsd-xdr
    2. cd to top level (bsd-xdr-1.0.0) in appropriate MSYS bash shell.
    3. follow instructions in README:

     $ cd mingw
     $ mv mgwxdr-0.dll /mingw32/bin/
     $ mv *.exe /mingw32/bin/
     $ mv *xdr* /mingw32/lib/
    /mingw32/bsd-xdr-1.0.0/mingw
     $ cd ..
    /mingw32/bsd-xdr-1.0.0
    $ mv rpc /mingw32/include/
    
    $ cd ..
    /mingw32
    $ rm -rf bsd-xdr-1.0.0/
    
     
    Last edit: GregJung 2015-01-29
  • GregJung
    GregJung
    2015-01-30

    Using Cmake with MSYS to build GDL

    Although CMake can be downloaded via pacman into the MSYS2 system it will still be native windows. I use Cmake for windows as it comes in binary form from cmake.org. For cygwin usage I use cmake built for cygwin X.

    Note in edit July, 2015
    Recently I've done a lot of experiments with cmake/MSYS2 combination configuration. (All of which used a cmake of version .ge. 3.0.1). When cmake is run in a unix system it will, from its modules/<xxx>.cmake and modules/Platform/<...>.cmake scripts, set up variables such that /usr/, /usr/local/, /opt/, /opt/local/ are all involved in the path discovery process. In the "MSYS Makefiles" case, I presumed this was also supposed to happen, so in my first mingw/msys installation I was building libraries and inserting them in the /usr/local/ tree and to find them I made modifications so that /usr and /usr/local were available for the cmake discovery process. By-and-large, this is incorrect, but usually harmless. the /usr tree should be dedicated to support of the MSYS component of mingw/msys (equal applicability to mingw.org's msys-1 and to msys-2) which is a mini-, stripped, analog to CYGWIN. (The difference msys-1 and msys-2.0 is, MSYS2 (msys-2.0) closely follows recent cygwin updates (and has a 64-bit version) while msys-1.0 stays put and is only in 32-bit version. (Whether one is 32- or 64- bit probably makes little to no difference whatsoever; either one can run with a 64-bit or a 32-bit compiler).

    I tend to build GDL using cmake-gui which can be invoked from the command line like cmake but which doesn't take the same number of optional arguments - in fact it may just be the source path that it takes. In the plus side I can see it's progress and re-run it after an error from the gui. A drawback is that to build cmake-gui you need a qt- installation. So my preference is to use CMake distributed in binary form (from www.cmake.org) for the windows platform, and run the same installation for each of three possible builds: mingw/msys(msys1), MSYS2: 32- and 64- bit mingw-w64 toolchains. When this is done, however, cmake (prior to version 3.3) will have no default knowledge that the mingw/ tree is significant. So this is why some strange-looking messages will be seen in the following exposition.

    When cmake is run from the mingw32 or mingw64 tree is will know of the libs waiting there to be incorporated, installed via pacman usually (although XDR needs a separate treatment, see below). Below, I simulated this situation using an external CMake (CMake-3.1.1-win32-x86) by setting the variable designed for such a purpose:

    CMAKE_LIBRARY_PATH=C:/msys64/mingw32/lib
    CMAKE_INCLUDE_PATH=C:/msys64/mingw32/include;

    Note that Cmake-gui is brain-dead about the mounted directories of the shell that spawned it.
    end updated note July 2015

    So I downloaded cmake-3.1.1 and, with my newly installed msys2/mingw32 toolbox, try to proceed:

    alias cmake311='/d/programs/CMake-3.1.1-win32-x86/bin/CMake-gui'
    
    cmake311 /f/tarball/gdl-141220/gdl/
    
    • clipping the last of the cmake output:

      Could NOT find PDCurses (missing: PDCURSES_LIBRARY PDCURSES_LIBRARIES PDCURSES_INCLUDE_DIR)
      PDCURSES_LIBRARY-NOTFOUND
      PDCURSES_LIBRARY-NOTFOUND
      PDCURSES_INCLUDE_DIR-NOTFOUND

      CMake Error at CMakeLists.txt:188 (message):
      PDCurses was not found.

      Use -DPDCURSESDIR=DIR to specify the curses directory tree.

    OK I didn't download the PDCurses. Not a pacman-available component. Instead I need change to gdl/Cmakelists.txt that allows ncurses to be used from win32. CMake also needs to be pointed to the support libraries. By changing some of the CMake scripting I get this set up: Messages from Cmake-gui after the first time the configure button is pressed and "MSYS Makefiles" is selected:

    $ cm3 /f/gdl/

    (cm3 = invoke cmake-3.0.1 with my modifications. /f/gdl/ also has modified cmake files. Later we will try our best with cmake3.1.1 without modifications).

     msys-X.0.dll found on C:/msys64/usr/bin  C:/msys64/usr
     <cmakeMSYSFindMake> MSYS Makefiles generator: 
         /usr path: C:/msys64/usr
         CMAKE_PREFIX_PATH=
    
        ( ...INCLUDE_PATH and LIBRARY_PATH are also set up)
     CMakeDetermineSystem> uname -s 
     MINGW32_NT-6.1 2.0.0(0.284/5/3)
    The C compiler identification is GNU 4.9.2
    The CXX compiler identification is GNU 4.9.2
     Platform/libpaths: inspecting PKG_CONFIG_PATH: (2 paths)
    CMAKE_LIBRARY_PATH: 
    C:/msys64/mingw32/lib;C:/msys64/opt/lib;C:/msys64/usr/local/lib;C:/msys64/usr/lib
    CMAKE_INCLUDE_PATH: 
    C:/msys64/mingw32/include;C:/msys64/opt/include;C:/msys64/usr/local/include;C:/msys64/usr/include
    CMAKE_PREFIX_PATH: 
     CMAKE_SHARED_LIBRARY_SUFFIX=.dll.a
    Check for working C compiler: C:/msys64/mingw32/bin/gcc.exe
    Check for working C compiler: C:/msys64/mingw32/bin/gcc.exe -- works
    

    Notice that /msys64/usr/ directories are involved; if anything is found and linked from these directories, it is an error (because /msys64/usr services MSYS builds not MINGW builds). CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH were built from a) the location of make.exe and identification of msys-X.0.dll in same directory; b) paths included in the PKG_CONFIG_PATH, LDFLAGS, and LIBRARY_PATHS environment variables.

    The rest of the cmake session went smoothly since I pre-defined PLPLOTDIR to be the directory where I targeted the plplot build. D:/bld/mingw32-psxdw2/plplot11 I call it plplot11 because it is a bit more advanced than plplot-5.10. But it isn't 5.11 yet, that will break everything!
    Note in edit July 2015 See https://sourceforge.net/p/gnudatalanguage/bugs/643/#1c2f and the post that follows it, which offers an alternate approach to the needed patch that will allow both >< plplot-5.11.
    end note

    Try standard cmake3.11 putting in the definitions:

    -G "MSYS Makefiles" \
    -DCMAKE_INSTALL_PREFIX=D:/bld/gdl32 \
    -DPLPLOTDIR=D:/bld/mingw32-psxdw2/plplot11 \
    -DCMAKE_LIBRARY_PATH=C:/msys64/mingw32/lib \
    -DCMAKE_INCLUDE_PATH=C:/msys64/mingw32/include \
    

    I do this in cmake-gui by use of the "add entry" button before any configuration is run.

    ok this looks ready:

    Summary
    
    GDL - GNU DATA LANGUAGE [Standalone]
    System              Windows-6.1
    Files generated     MSYS Makefiles
    GDL output          D:/bld/gdl/mingw32/src/gdl.exe
    Installation prefix D:/bld/gdl32
    C++ compiler        C:/msys64/mingw32/bin/g++.exe -O3 -DNDEBUG
    
    Options
    OpenMP support      ON -fopenmp
    WxWidgets           OFF
    ImageMagick         OFF
    NetCDF              OFF
    HDF4                OFF
    HDF5                OFF
    FFTW                ON C:/msys64/mingw32/lib/libfftw3.dll.a;C:/msys64/mingw32/lib/libfftw3f.dll.a
    Libproj4            OFF
    MPICH               OFF
    Python              OFF
    UDUNITS-2           OFF
    EIGEN3              OFF
    GRAPHICSMAGICK         OFF
    GRIB                OFF
    GSHHS               ON F:/gdl/src
    pslib               OFF
    libpng              ON 
    Cairo drivers for X or WIN         ON 
    Xlib                OFF
    
    Mandatory modules
    Plplot              ON D:/bld/mingw32-psxdw2/plplot11/lib/libplplot.dll.a;D:/bld/mingw32-psxdw2/plplot11/lib/libplplotcxx.dll.a
    Old Plplot          OFF
    Readline            ON C:/msys64/mingw32/lib/libreadline.dll.a;C:/msys64/mingw32/lib/libhistory.dll.a
    GSL                 ON C:/msys64/mingw32/lib/libgsl.dll.a;C:/msys64/mingw32/lib/libgslcblas.dll.a
    Zlib                ON C:/msys64/mingw32/lib/libz.dll.a
    (N or PD)curses             ON C:/msys64/mingw32/lib/libncurses.a
    
    Configuring done
    

    This is the default mode for my builds, to make the minimum functional GDL.
    - FFTW is more than the minimum but it has never been a problem.
    - graphicsmagick has not been working with win32 so I will leave it out.
    - proj can be included. already downloaded.
    - hdf5 is available in msys2 but cdf is not; I had problems earlier trying to build netcdf.
    - EIGEN3 has presented issues before but is now ok (using cvs)
    - Bringing python into the build would greatly increase the header compilation overhead. Until I want it, I don't need it.

    • PSLIB is a problematic addition: a rudimentary PS driver comes in without pslib. Heck, it version number hasn't even reached 1.0 yet ! SVG is a better choice for hardcopy output but the PS device will also work without including PSLIB.

    • Cairo drivers are a specialized build for me. They do ok with vector graphics but images haven't been programmed in.

    I'm going to turn proj4 on, graphicsmagick ON, wxwidgets ON and run configure again.

    The following new variables appear:

    GRAPHICSMAGICXX_LIBRARY        C:/msys64/mingw32/lib/libGraphicsMagick++.dll.a
    GRAPHICSMAGIC_LIBRARY           C:/msys64/mingw32/lib/libGraphicsMagick.dll.a
    wxWidgets_CONFIG_EXECUTABLE     C:/msys64/mingw32/bin/wx-config
    wxWidgets_wxrc_EXECUTABLE      C:/msys64/mingw32/bin/wxrc.exe
    

    And the options list shows the added options:

    Options
    OpenMP support      ON -fopenmp
    WxWidgets           ON -L/mingw32/lib;-pipe;-Wl,--subsystem,windows;-mwindows;-lwx_baseu-3.0;-lwx_mswu_core-3.0;-lwx_mswu_adv-3.0
    ImageMagick         OFF
    NetCDF              OFF
    HDF4                OFF
    HDF5                OFF
    FFTW                ON C:/msys64/mingw32/lib/libfftw3.dll.a;C:/msys64/mingw32/lib/libfftw3f.dll.a
    Libproj4            ON C:/msys64/mingw32/lib/libproj.dll.a
    MPICH               OFF
    Python              OFF
    UDUNITS-2           OFF
    EIGEN3              ON 
    GRAPHICSMAGICK         ON C:/msys64/mingw32/lib/libGraphicsMagick++.dll.a;C:/msys64/mingw32/lib/libGraphicsMagick.dll.a
    GRIB                OFF
    GSHHS               ON F:/gdl/src
    pslib               OFF
    libpng              ON 
    Cairo drivers for X or WIN         ON 
    Xlib                OFF
    

    The final build line created by CMake3.1.1 branches out to linklibs.rsp.
    src/CMakeFiles/gdl.dir/build.make {near line 3500)

        cd /D/bld/gdl/mingw32/src && /C/msys64/mingw32/bin/g++.exe  -O2 -mtune=pentium3 -O3 -DNDEBUG   \
        -Wl,--whole-archive CMakeFiles/gdl.dir/objects.a -Wl,--no-whole-archive  \
        -o gdl.exe -Wl,--out-implib,libgdl.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/gdl.dir/linklibs.rsp
    

    linklibs.rsp:

    -L/mingw32/lib -lshlwapi -lgnurx -ltermcap antlr/libantlr.a -lws2_32 -lz -lpng -lgomp -lpthread -lgsl -lgslcblas -lxdr -lpcre -lreadline -lhistory -Wl,-Bstatic -lncurses -Wl,-Bdynamic D:/bld/mingw32-psxdw2/plplot11/lib/libplplot.dll.a D:/bld/mingw32-psxdw2/plplot11/lib/libplplotcxx.dll.a -lfftw3 -lfftw3f -lGraphicsMagick++ -lGraphicsMagick -L/mingw32/lib -pipe -Wl,--subsystem,windows -mwindows -lwx_baseu-3.0 -lwx_mswu_core-3.0 -lwx_mswu_adv-3.0 -lproj -lshlwapi -lgnurx -ltermcap -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

    $ make >& make0.out

    Be advised, this is output from a custom Cmakelists.txt, CMakeModules/. This is my first MSYS2 build using mingw32=mingw-w64-i686. Previously, to get a 32-bit build I used with mingw/msys(-1.0) from mingw.org, And the collected libraries compiled thereby. The compilers of this installation are of a different version (vintage, thread, and exception) than those provided from MSYS2-pacman, so it is not wise to mix them in.

    greg@Homerw7 MINGW32 /d/bld/gdl/mingw32
    $ make >& make0.out &

    greg@Homerw7 MINGW32 /d/bld/gdl/mingw32
    $ ps
          PID    PPID    PGID     WINPID   TTY     UID    STIME COMMAND
         3416       1    3416       3416  ?       197609 07:48:16 /usr/bin/mintty
         1296    3416    1296       5000  pty0    197609 07:48:16 /usr/bin/bash
         1964    3592    2956       3544  pty0    197609 12:03:18 /usr/bin/sh
         3592    3376    2956       4368  pty0    197609 12:02:49 /usr/bin/make
         2956    1296    2956        712  pty0    197609 12:02:28 /usr/bin/make
         3376    2956    2956       1892  pty0    197609 12:02:28 /usr/bin/make
          996    1964    2956       4492  pty0    197609 12:03:18 /mingw32/bin/g++
         4148    1296    4148       4240  pty0    197609 12:03:39 /usr/bin/ps
    I    4772     372    4772       1848  pty1    197609 09:10:22 /usr/bin/bash
          372       1     372        372  ?       197609 09:10:22 /usr/bin/mintty
    

    Now that I have a quad processor I've learned that I can run 4 parallel compilations by using make -j4 - completes in 1/4 time. Make -j6 brings out 6 parallel processes. This doesn't work at all for me in mingw/msys-1.0, the process hangs, although I hear there exists a version for msys-1.0 that does work. Sometimes it will hickup anyway and a build may need to be restarted.

    The above fails to compile because, in bringing wxWidgets in, the wx-config script did not have the full directory path in the prefix. Edit this around line 402: prefix=${input_option_prefix-${this_prefix:-C:/msys64/mingw32}} where C:/msys64 was not there before.

    another try, and we're still stuck in <wx wx.h="">:

    [ 41%] Building CXX object src/CMakeFiles/gdl.dir/gdleventhandler.cpp.obj
    In file included from C:/msys64/mingw32/i686-w64-mingw32/include/windows.h:72:0,
                     from C:/msys64/mingw32/i686-w64-mingw32/include/winsock2.h:23,
                     from F:/gdl/src/gdleventhandler.cpp:27:
    C:/msys64/mingw32/include/wx-3.0/wx/msw/winundef.h: In function 'HWND__* CreateDialog(HINSTANCE, LPCTSTR, HWND, DLGPROC)':
    C:/msys64/mingw32/include/wx-3.0/wx/msw/winundef.h:38:20: error: cannot convert 'LPCTSTR {aka const char*}'
    

    winundef.h needs to be changed, or UNICODE needs to be defined for all compilations. Basically the header file tries to save some characters by defining the function once with a generic name and does the #ifdef _UNICODE dance in the function definition.

        inline HWND CreateDialog(HINSTANCE hInstance,  // created our error
                                 LPCTSTR pTemplate,
                                 HWND hwndParent,
                                 DLGPROC pDlgProc)
        {
            #ifdef _UNICODE
                return CreateDialogW(hInstance, pTemplate, hwndParent, pDlgProc);
            #else
                return CreateDialogA(hInstance, pTemplate, hwndParent, pDlgProc);
            #endif
        }
                   // The function version:
            #ifdef _UNICODE
        inline HWND CreateDialog(HINSTANCE hInstance,
                                 LPCWSTR pTemplate,
                                 HWND hwndParent,
                                 DLGPROC pDlgProc)
        {
                return CreateDialogW(hInstance, pTemplate, hwndParent, pDlgProc);
        }
            #else
         inline HWND CreateDialog(HINSTANCE hInstance,
                                 LPCSTR pTemplate,
                                 HWND hwndParent,
                                 DLGPROC pDlgProc)
        {
               return CreateDialogA(hInstance, pTemplate, hwndParent, pDlgProc);
        }
            #endif
    

    I did edit winundef.h to accomodate and tried to make a stink about it with wx;
    Anyway once this was done, my msys2/mingw_64_i686 gdl built with wxWidgets.

     
    Last edit: GregJung 2015-07-22
    • GregJung
      GregJung
      2015-01-30

      The 32-bit build won't run from the msys shell, but it will run from a windows shell. I found that, running the GDL linked with wxWidgets produced a lot of troublesome errors for me, even without calling on the (nascent) widget capability.

       
      Last edit: GregJung 2015-04-12