Menu ▾ ▴

New MinGW GnuCOBOL 3.1 RC1 binary available for download

Help getting started
Arnold Trembley
2020-07-01
2020-07-05

  • Arnold Trembley

    Arnold Trembley - 2020-07-01

    Here is a link to a MinGW binary for GnuCOBOL 3.1 rc1 (30JUN2020), with BDB, GMP 6.2.0, and PDCurses 4.1.99. This build has additional support for debugging the compiler itself:

    https://www.arnoldtrembley.com/GC31-rc1-G-BDB-rename-7z-to-exe.7z
    https://www.arnoldtrembley.com/GnuCOBOL-3.1-rc1-MinGW-Build-Guide-V7.pdf
    https://www.arnoldtrembley.com/GnuCOBOL-3.1-rc1-MinGW-Build-Guide-V7.docx

    I am still having some difficulty building PDCurses 4.1.99. The colors and characters should be working correctly, but cobcrun --info shows "unknown" for mouse support. I don't know what went wrong with that.

    If that looks reasonable I will build the typical binaries for BDB, VBISAM, and No-ISAM (without compiler internals debugging support).

    Any feedback on pdcurses issues would be appreciated. I can always go back to 3.9.

     
    👍
    1

    • Simon Sobisch

      Simon Sobisch - 2020-07-01

      Thank you for the build, that was fast.

      cobcrun --info shows "unknown" for mouse support

      That is not necessarily a bad thing. cobcrun --info was adjusted to only show the entries it can get without initializing curses - as this breaks some setups.
      If you are directly on the command line (and only in this case) you can see the full output by cobcrun -v --info.

      Concerning PDcurses - espeically when building with PDCurses4: please build the PDcurses ports winco, wingui and vt - "install" in the package whatever you find working best (maybe the "legacy" variant wincon, maybe the new vt) as pdcurses.dll and keep all different versions in the "bin" directory as pdcurses_wincon.dll, pdcurses_wingui.dll, pdcurses_vt.dll; this will allow people to just copy+rename and to work with a different port. Everything is expecting to work fine with this approach, as long as the PDCurses version and the CHTYPE/WIDE/UTF8 options used for building the ports are the same.
      cobcrun --info will show the same for all of those, but cobcrun --verbose --info should show the differences.

       

    • thomas

      thomas - 2020-07-01

      Hi Arnold,

      Thanks for the Built, please also do a built for 64-bit as well since the other one you did in 2018 is outdated.

       

      • Simon Sobisch

        Simon Sobisch - 2020-07-01

        I think Arnold just took the MSYS2-package binaries and re-packed them.
        3.1-rc1 was already setup there and now needs to be "checked" (looks like this needs some hours), then "merged/accepted" by its maintainers and then built, the last time this process took something about a week.
        Edit: all "manual" parts are finished already we are now in the place where the documentation says:

        Please note that this doesn't make the package immediately available through pacman. The binary repositories are updated in bursts.

        As an alternative: if you have MSYS2 already or get it you can create the GnuCOBOL binaries using the file linked above now official recipe yourself at any time (results in both 32 and 64bit environment, with up-to-date build system and dependencies and screenio based on wide ncurses btw).

         

        Last edit: Simon Sobisch 2020-07-01

      • Anonymous

        Anonymous - 2020-07-01

        Help me to understand the need for a 64 bit Cobol compiler.
        Is it that you have Cobol modules that require more than 2,147,483,648 bytes of addressable memory ?
        Seems akin to needing 16+ cores.
        Whatever

         

        • Simon Sobisch

          Simon Sobisch - 2020-07-01

          "need" is always relative; some things to remember here:

          • the limit is not primarily "per module" but "for the complete process with all its modules
          • COBOL is a bit special concerning memory when compared to other environments - there is no procedure-local storage (at least not by default, COBOL2002 would allow you to manually have this with ALLOCATE and FREE and WORKING-STORAGE data is persitent between runs; combined with the default of "you need to have the maximum OCCCURS defined that you may want to access this often leads to "bigger" memory use "up-front" (without a conditional "may brake any time [and will often slow down] on reallocation" other environments feature)
          • most COBOL environments do not free the modules data on CANCEL (many have the option to activate that, as GnuCOBOL has too), so the data stays persistent as long as the process runs
          • if you want to directly use COBOL from a 64bit application without any IPC then the COBOL part needs to be 64bit, same if you want to directly CALL into a library that is only available as 64bit
           

          • Ralph Linkletter

            Ralph Linkletter - 2020-07-01

            I would think that the OS would support a Thunk between 32 <--> 64 bit applications.
            It doesn't ?
            2 billion bytes is astronomical (even combined with n+ modules) and mind staggering - even in 2020.
            I can understand if caching SQL - but that caching is not at a Cobol level but rather the DBM.
            Strange :-)
            Ralph

             

        • Vincent (Bryan) Coen

          Vincent (Bryan) Coen - 2020-07-01

          If you are running a x64 system why would you want to do x86 ?

          It is not just access to Ram as the x64 instruction set is a lot more
          efficient and therefore faster.   How much faster does depend on a lot
          of factors and how long the program runs for but I do have examples of
          programs that are running 24/7 although do have some rest periods via SLEEP.

          On 01/07/2020 14:51, noreply@sourceforge.net wrote:

          Help me to understand the need for a 64 bit Cobol compiler.
          Is it that you have Cobol modules that require more than 2,147,483,648
          bytes of addressable memory ?
          Seems akin to needing 16+ cores.
          Whatever

           

          • Ralph Linkletter

            Ralph Linkletter - 2020-07-01

            Are you saying that a 64 bit Cobol in consortium with the OS in consortium with the CPU will fetch 8 bytes per machine / clock cycle?
            If so I agree it is faster,
            But if there is "thunking" required then I would expect it to be slower than a vanilla 31 / 32 bit application.

             

            Last edit: Ralph Linkletter 2020-07-01

      • Simon Sobisch

        Simon Sobisch - 2020-07-04

        MSYS2 packages are shipped - mingw-w64-x86_64-gnucobol and mingw-w64-i686-gnucobol gives you 3.1rc1 with BDB 6.0.19, GMP 6.2.0, libxml 2.9.10, ncursesw 6.2..20200212.

        Just a note: if you want to use this within the MinGW shells you have to set either TERMINFO to usr/share/terminfo or unset TERM (which normally is set to xterm),

        So @ anyone - you can use this new version by installing via pacman now, too (or - as I did, just let pacman update your packages if you have it installed already).
        @arn79 if you want to you could create a mingw64 based 32-bit and 64-bit package now, too.

         

        Last edit: Simon Sobisch 2020-07-04

    • Eugenio Di Lorenzo

      Eugenio Di Lorenzo - 2020-07-01

      Hi Arnold, as always: good job ! Thanks a lot.
      In this version the colors are displayed correctly and the mouse keys also are working well.
      To test the mouse I used the GC99MOUSEDEMO program which is located in contrib \ trunk \ tools \ TUI-TOOLS.

      There is still the problem of the right-doubleclick which is not detected but I think this is a compiler bug (code 2049 that is not detected).

      See BUG ticket num. 608 at https://sourceforge.net/p/open-cobol/bugs/608/#d14c
      It appears simple to fix but it is still open.

       

      Last edit: Eugenio Di Lorenzo 2020-07-02

Anonymous
Anonymous

Add attachments
Cancel