GDL executable for Windows

divenex
2011-07-29
2014-08-20
  • divenex
    divenex
    2011-07-29

    I have seen some requests on the trackers (e.g. ID: 2138215 and 3373046) for a GDL executable for Windows. However I understand the core developers feel there is no much interest in GDL for Windows.

    This seems like a "chicken and egg" problem: Windows users like me, who land on the GDL home page while looking for a free IDL clone, will be turned away by the lack of any mention of Windows support. Windows users still represent the largest user base for IDL, so it would be useful to provide them with an easy migration path towards GDL.

    Few IDL Windows users have the expertise to install Cygwin and even less to apply patches and compile source code. So the key to attract any interest is to make Windows executable available.

    I would love to help with this, if I can do it, and for this I would be grateful if anybody could provide detailed instructions about producing GDL executables for Windows. It would be very useful to post those instructions on the GDL website, together with a mention that GDL runs on Windows (if this is the case). Alternatively, if anybody has already produced GDL executables, it would be useful to post them on the GDL website. Thank you.

     
    • Jeongbin Park
      Jeongbin Park
      2014-03-29

      I made a project for win32 distribution temporarily.

      https://sourceforge.net/projects/gnudatalanguage-win32

      Please try it, and feedback welcome.

       
      • John Arthur
        John Arthur
        2014-04-01

        Thanks for a great initiative! Clearly there's a large number of potential Windows GDL users out there.
        The installation of your .exe went very smoothly, but, unfortunately, the initial version does not work too well, at least not on my PC. Square and curly brackets are not recognized (AltGr-7/8/9/0 on my PC), and a simple plot command for an array creates a window that just hangs. I am running Windows 7. I am very much looking forward to the next version where (probably small) bugs like these are fixed. Support for Copy and Paste would also be extremely useful. I also see that you are working on the SPAWN problem. Great! Keep up the good work!
        Regards,
        John Arthur Skard

         
        • Jeongbin Park
          Jeongbin Park
          2014-04-03

          Could you post your square and curly bracket test code here, so that I can try it and fix the issue?

           
          Last edit: Jeongbin Park 2014-04-03
          • John Arthur
            John Arthur
            2014-04-06

            No particular code involved. I just type e.g. a=[...] on the command line, and the brackets do not appear. So cannot define a vector array, for example. Same with curly brackets, {}, they also don't appear, and the program understands nothing, of course, when the brackets are missing... :-(
            It appears that the interpretation of keyboard input on the command line is not fully (or correctly) developed/implemented. Copy and paste into the command line is also a very useful feature that does not work.
            I am using a 64-bit Acer desktop, standard keyboard, Windows 7 Premium Home edition.

             
            Last edit: John Arthur 2014-04-09
    • GregJung
      GregJung
      2014-05-05

      I'm trying to get GDL to compile using Mingw32/Msys.
      I started the build chain for cygwin, but early on it will require "X"; I'd rather
      not need all that to run it. Also, the MSYS environment so far seems more friendly.
      After approaching this several times in the past 15 years I'm still novice but delving more consistently this time around - for as long as it lasts.

       
  • Leo Anderson
    Leo Anderson
    2013-02-15

    I am in the process of building a gdl executable for windows. Please advise if you are still interested.

     
  • Alain C.
    Alain C.
    2013-02-18

    up to now, none of GDL core developers are using MS-win.

    Then we very welcome any feedback. And we will try to add ASAP any patch in the CVS if any.

    please notice we know that about 1/4 of the test cases in testsuite/ will failed because of use of SPAWN. We have no solution today.

     
  • GregJung
    GregJung
    2014-05-17

    SO, ok now I've been banging my head on this a while ... compiling with MSYS
    now GDL uses, as does PLPLOT package, CMAKE to build; I'm concentrating on getting plplot to full functionality - I was able to build it but the test programs didn't hook in.
    The upfront problem I'm getting is with cmake: already the variables
    WIN32=MINGW=MSYS=1 with the "MSYS Makefiles" generator but there is little associated logic in the cmake modules. It looks like /usr is not a recognized mount point - find_path isn't working through /usr/include or /usr/local/include. CYGWIN case has a similar problem, even though the cmake is linked through cygwin.dll.

     
    Last edit: GregJung 2014-05-17
  • GregJung
    GregJung
    2014-08-11

    Revisit: I've finished my bout with cmake, most of the MSYS problems related to
    the more complicated library-finding aspects, and the desire to include freetype2, with
    its quirky setup, in the PLPLOT build. These issues ought to
    be skirted until the nub issues are defined- based on the behavior of J.Park's build
    via MINGW-TDM, contrasted with great performance under Cygwin.
    I was able to test the relevant driver under PLPLOT/MSYS build and it (wingcc) seems to be fine w.r.t. the basic stuff gdl is failing with now.
    The next step would be to slice the (plot, window, wdelete,cursor) interface from gdl, wed it to plplot/wingcc, work on that.

     
  • GregJung
    GregJung
    2014-08-13

    Now that I've started to read the GDL plotting source code it appears I had my head up my *ss bothering so much about PLPLOT, apparently the gdl code has already been stripped down to just a few devices, ("X","WIN","NULL","SVG","PS","Z"), and code used for these drivers is included in the gdl/src/devicexxx.hpp files.

     
    • Alain C.
      Alain C.
      2014-08-14

      not sure to understand the beginning of this message !

      yes, we only manage a few devices, ("X","WIN","NULL","SVG","PS","Z")

      yes, codes used for these drivers is included in the gdl/src/devicexxx.hpp files.

      I strongly suggest you read the code in the current CVS version because large
      changes were made by Gilles during last months.

      Alain

       
      • GregJung
        GregJung
        2014-08-19

        To clarify:
        To build GDL on Mingw one needs to compiles all of the preceding libraries that
        it calls, and before that the libraries they depend on, etc. From the unix-based distributions. To do this for linux is almost trivial because everything you do
        has been done 1000+ times before by other users and the kinks have been smoothed.
        So it is a big deal to get to the part where the gdl code itself can be linked,
        and the biggest package in the way is PLPLOT. Except, gdl only uses trivial aspects of PLPLOT code - which I didn't know until I read through code in the GDL tree.
        I suspected problems in the WIN plot device were due to the device driver for plplot
        and so I spent a lot of time carefully building that, which is more complicated than a gdl build. Fortunately I don't really mind because I'm relatively novice to the whole process.
        Yes I've been working with a recent distribution.

         
  • GregJung
    GregJung
    2014-08-19

    I've recently succeeded in building gdl for mingw32; I had to make several passes
    get a compilation, and it required manual manipulation of the final build command,
    some of which are as follows:

    1. The -fopenmp option was used so GCC generates code that will require the Gomp library
      but build.make asked for vcomp; this is a CMAKE issue I guess. s/vcomp/lgomp/
    2. time.h, sys/time.h, gtdhelper.hpp each have some opinion about timezone which had to be resolved. I may have broken my distro to fix it.
    3. semaphore.h and -lpthread
    4. -lregex was needed, maybe becaus I didn't bring in the perl library stuff.
    5. readline/ncurses: I needed to satisfy some termcap functions this is probably because my build of ncurses didn't go well.

    The resultant gdl.exe runs ok from a DOS shell but the line-editor key response is sluggish. window, wset, wdelete work (as in, they dont crash the program). When a graphics window is created the focus should return to the terminal; wdelete should kill the window, not just detach and forget it; if a tek cursor can't be called up a simple large plus-sign cursor could be employed for the CURSOR routine.

     
  • giloo
    giloo
    2014-08-19

    "line-editor key response is sluggish". It can be the case under linux, too. It can come from libreadline, if you use it in the window build. See discussion https://sourceforge.net/p/gnudatalanguage/bugs/562/

     
    • GregJung
      GregJung
      2014-08-20

      I am most suspicious about my ncurses build; only libraries with the name ncursest
      get generated, which I copied to ncurses. Then, to link the mingw version, I had
      to again come up with a termlib to satisfy remaining externals. My first cygwin build
      has great line response in X, it uses readline with ncurses I downloaded pre-built.