GDL executable for Windows

divenex
2011-07-29
2014-10-21
  • 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.

       
      • GregJung

        GregJung - 2014-10-21

        Getting cygwin to compile was easy once a certain #ifdef..#endif was modified to piggyback the CYGWIN case with the WIN32 case. inclde/xdr/xdr,types. These are fixed in 0.9.5 now. But recently a cygwin64 update took these headers out of my configuration, so beware of that. Otherwise the -basic- configuration builds fine, and runs well; SVG, X devices have been in recent development and work the best. All this, after I've done "startx" and am running twm. Under different X-server conditions: your results may vary. I also hit roadblocks, maybe small, trying to bring in CDF, HDF5 etc.

         
        Last edit: GregJung 2014-10-21
  • 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.

    Comment 2015-08-04:
    When I posted this I didn't realize ,libraries under /usr should not be contributing when building for MINGW using msys; except for possible /usr/local (where builds may tend to be put).
    Also, cmake will find items in the tree from which it was run, and from the compiler's tree. So if /mingw/cmake is used then mingw/lib directory can hold most of the support. Addirional directories can be added via CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH definitions. Starting in cmake3.3.0, /lib and /include directories will also be discovered through the PATH environment variable; so if that's a mess from windows' installation, think about cleaning it up for msys usage.

    See also the other topic HOWTO build on windows has more current explanations.

     
    Last edit: GregJung 2015-08-04
  • 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.

       
    • GregJung

      GregJung - 2014-10-21

      I've now done quite a bit of experimentation w.r.t. readline, curses, ncurses., etc. Somehow the GDL parser input, buffering, or threading, or dependence on exception handling don't play well with the usual assumptions of terminal input.
      (I compile with gcc -fopenmp using mingw/msys so linkage is -gomp -pthread if that means anything.) linking with readline6 and (either pDcurses or) ncurses5 result in bad behaviors (mingw32 build).
      My best result is linking with readline5 followed by regex.a and libtermcap.a. Cygwin behavior is fine with readline/ncurses.

       
      Last edit: GregJung 2014-10-21

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks