This package includes Chuck Haatvedt's MSYS2 build scripts from August, for those of you who want to build your own Windows MSYS2 GnuCOBOL 3.2 compiler. The kit includes a build guide (.pdf and .docx), bash build scripts, GnuCOBOL manuals, and some additional files for packaging with a binary compiler.
Chuck's updated scripts give you options for building 32-bit or 64-bit compilers, with either BDB 18.1.40, or BDB 6.0.19 (with the Sleepcat license), or VBISAM 2.1.1.
With this kit you should be able to build the newer binaries similar to the ones available for download at:
I want to thank you once again for this precious work you are doing.
I take this opportunity to tell you that it would be useful to have some information on the specific characteristics of this version of the compiler.
Even better would be to be able to have comparison information between the GnuCOBOL version for MINGW and the GnuCOBOL version for MSYS.
What do you think about this?
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that "MinGW w64" toolset uses the MSYS2 shell by default, and I will refer to it as MSYS2 to distinguish it from the older 32-bit MinGW toolset. MSYS2/MinGW64 is able to create 32-bit or 64-bit GnuCOBOL compilers. MinGW is only able to create 32-bit compilers.
In general, GnuCOBOL 3.2 is the same whether it is built with older MinGW or MSYS2. But a 64-bit MSYS2 GnuCOBOL might allow larger in-core tables or working-storage sizes.
The biggest advantage to using MSYS2 is that Chuck Haatvedt's scripts will build GnuCOBOL with full Gnu Debugger support, plus the COBOLWORX debugger specifically written for GnuCOBOL, and this requires a full Python 3 Interpreter which adds over 100 megabytes to the size of the generated binary.
The MSYS2 toolset includes a more modern embedded GCC compiler, version 13.1.0, compared to the older MinGW which uses GCC version 9.2.0. Currently osdn.net (where MinGW32 is hosted) is going through server upgrades, so it has not been possible to download the older MinGW since late July.
The MSYS2 binaries are quite large compared to the MinGW binaries, about 730 megabytes uncompressed (96 megabytes compressed) for an MSYS2 build versus 166 megabytes uncompressed (25.6 megabytes compressed) for a MinGW build.
If you really need the best debugging support for your GnuCOBOL programs, then you would likely prefer the MSYS2 builds. If you really need 64-bit address support in your GnuCOBOL programs then you would want a 64-bit MSYS2 build.
Kind regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the very clear and detailed answer.
I could summarize that there are two characteristics of difference that you pointed out:
a. the ability to manage larger memory volumes
b. the ability to use the gdb debugger
Being able to use a debugger would be very, very important.
Unfortunately my feeling is that this solution of using gdb is not yet what we need becouse I don't think it's something easy to install (those who tried apparently had to struggle a lot before having a working solution), the dimensions it brings with it, the need to have Phyton ...
After a few years of experience with the GnuCOBOL product, which is now close to version 4, I think we are not there yet.
GIX forces you to use a different IDE, I can't say how complete and reliable it is still
In my opinion we don't have a simple enough debugger yet.
A few years ago a fork called OCEAN (Open Cobol Embedded Animator) appeared which promised just what was needed (a complete written solution of animation just for GnuCOBOL and similar to others ANIMATORS) but then the project was stopped.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Writing a GnuCOBOL debugger is no trivial task. There are User Interface and system control requirements that don't exist in normal business applications programming.
I wish there was something similar to Compuware Xpediter, but for GnuCOBOL (either fixed format or free format) that would also work with GnuCOBOL on Linux or MacOS as well as Windows.
GDB already exists, but it is built to debug the intermediate C code. COBOLWORX tries to solve that with its owl tools. It all "sort of" works, but it is not easy to set up, and takes a fairly long time to learn. The example of Python also suggests that approach uses a lot of machine resources.
I am generally content to use the MinGW32 compilers and throw some display statements in. That works pretty well for batch programs and doesn't require a lot of additional tools or resources.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While that looks like a bit of topic drift: Getting used to GDB (using COBOLworx extensions) did took some time for me, too - but now I'm really very fast with that now. I also have seen that with COBOL-only colleagues that only used Animator before, which tell me that after using it several times they are now faster with GDB (we use a frontend so you don't need to type anything in the gdb command and always see your COBOL code).
Additional GDB brings in a lot of options and external tools leveraging it, for me especially valgrind and rr, and allows easy attach and even remote debugging options.
Note: There are also GDB frontends which don't use the COBOLworx extensions, below them are gnucobol-debug for vscode and (added recently, still "early version") cobgdb which provides an animator-like command line tool. Both possibly also work with the "old" MinGW toolset. Who volunteers to test that?
Last edit: Simon Sobisch 2023-10-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is not clear whether you are referring to the test of Oleg's debugger or to the test of the new cobgdb solution.
It is not even clear what the difference is between the two solutions and why .
If Oleg's debugger is working then why is anyone else moving forward with a new debugger like cobgdb ?
My system is Windows 10 and I only use the Mingw version downloaded from Arnold.
However if it is ok, then I am available to proceed with the necessary testing phases.
I believe that your support will be needed at least to set up the test environment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
test both for "ease of use" (no GDB knowledge or command use or python or cobcd)
test cobgdb as "animator like"
It is not even clear what the difference is between the two solutions and why.
gnucobol-debug is a vscode extension (you need vscode, you'll use its debug controls)
cobgdb is a terminal application, just as "animator" is (you will use hotkeys for controlling the debugger)
If Oleg's debugger is working then why is anyone else moving forward with a new debugger like cobgdb ?
Because of the different user interface and principles. And of course "no software is perfect" (I find that currently both don't work well for "production environments" with hundreds or thousands of modules because of some design issues - but my feeling is that cobgdb gets there faster).
My system is Windows 10 and I only use the Mingw version downloaded from Arnold.
That should work. As both use GDB to interact with the process "under the hood", you needs a working GDB version 6.0+. As far as I know even "old" MinGW (Sept 2013) distributes GDB 7.6.1; newer versions (Aug 2020) provides GDB 9.2.
If it isn't contained you can also use another binary, for example from https://github.com/noword/GDB-Windows-Binaries.
I believe that your support will be needed at least to set up the test environment.
Please check the project's README, those should be clear enough. If not then please contact the poject author, either by creating an issue in their repo or by sending them a mail.
One hint: If using Arnold's build and start with set_env.cmd (vs. system installation), then you'll first close all instances of vscode, then open set_env.cmd and from this command window open vscode (or cobgdb). Whichever version of GDB you use, it should be in PATH and named "gdb" (exe/cmd/bat) to be easily found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Arnold
I have been trying to run this build, but can not get step 7 or step 8 to run.
I get the message that the required first input parm is missing.
I have tried both to copy and paste, and to type the input. I get the same error either way.
source build-x32.sh | tee build-x32.txt
is what I entered.
Other than the number of processors (cpu_count), I used all defaults. I used NotePad to edit the two files.
This is my first attempt to use one of your builds. The install pdf is very clear in what to do. Im on windows 10 and currently use 3.1.2.0 with no issues. I just wanted to try 3.2 again to see if the problems I have with my virus software still exist.
I Duh Know.
Michael :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Make sure you have the name of the script typed correctly, and that you're starting in the right folder and starting in the right MSYS2 component (MSYS2 MINGW32 or MSYS2 MINGW64). Don't start in the MSYS2 task. I tend to set the cpu_count to 1, but that will make the build run longer.
Be sure to include the full command, without the slash, for example:
source build-x32.sh | tee build-x32.txt
or
source build-x64.sh | tee build-x64.txt
And if you're still having problems we can contact Chuck Haatvedt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Arnold
I quadruple checked what and where I was doing the things.
I even deleted and restarted from scratch 3 times.
The error messages are coming from the build sh files.
I Duh know.
Michael :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I apologize for being so late in updating this, but here is a link to the updated MSYS2 build kit:
https://www.arnoldtrembley.com/MSYS2-Build-Kit-v07.7z
This package includes Chuck Haatvedt's MSYS2 build scripts from August, for those of you who want to build your own Windows MSYS2 GnuCOBOL 3.2 compiler. The kit includes a build guide (.pdf and .docx), bash build scripts, GnuCOBOL manuals, and some additional files for packaging with a binary compiler.
Chuck's updated scripts give you options for building 32-bit or 64-bit compilers, with either BDB 18.1.40, or BDB 6.0.19 (with the Sleepcat license), or VBISAM 2.1.1.
With this kit you should be able to build the newer binaries similar to the ones available for download at:
https://www.arnoldtrembley.com/GC32M-BDB-x64.7z
https://www.arnoldtrembley.com/GC32M-BDB-x32.7z
Many thanks to Chuck Haatvedt and Simon Sobisch for all their hard work in developing these build scripts.
Kind regards,
I want to thank you once again for this precious work you are doing.
I take this opportunity to tell you that it would be useful to have some information on the specific characteristics of this version of the compiler.
Even better would be to be able to have comparison information between the GnuCOBOL version for MINGW and the GnuCOBOL version for MSYS.
What do you think about this?
You can read about both MinGW toolsets in Wikipedia:
https://en.wikipedia.org/wiki/MinGW
https://en.wikipedia.org/wiki/Mingw-w64
Note that "MinGW w64" toolset uses the MSYS2 shell by default, and I will refer to it as MSYS2 to distinguish it from the older 32-bit MinGW toolset. MSYS2/MinGW64 is able to create 32-bit or 64-bit GnuCOBOL compilers. MinGW is only able to create 32-bit compilers.
In general, GnuCOBOL 3.2 is the same whether it is built with older MinGW or MSYS2. But a 64-bit MSYS2 GnuCOBOL might allow larger in-core tables or working-storage sizes.
The biggest advantage to using MSYS2 is that Chuck Haatvedt's scripts will build GnuCOBOL with full Gnu Debugger support, plus the COBOLWORX debugger specifically written for GnuCOBOL, and this requires a full Python 3 Interpreter which adds over 100 megabytes to the size of the generated binary.
The MSYS2 toolset includes a more modern embedded GCC compiler, version 13.1.0, compared to the older MinGW which uses GCC version 9.2.0. Currently osdn.net (where MinGW32 is hosted) is going through server upgrades, so it has not been possible to download the older MinGW since late July.
The MSYS2 binaries are quite large compared to the MinGW binaries, about 730 megabytes uncompressed (96 megabytes compressed) for an MSYS2 build versus 166 megabytes uncompressed (25.6 megabytes compressed) for a MinGW build.
If you really need the best debugging support for your GnuCOBOL programs, then you would likely prefer the MSYS2 builds. If you really need 64-bit address support in your GnuCOBOL programs then you would want a 64-bit MSYS2 build.
Kind regards,
Thanks for the very clear and detailed answer.
I could summarize that there are two characteristics of difference that you pointed out:
a. the ability to manage larger memory volumes
b. the ability to use the gdb debugger
Being able to use a debugger would be very, very important.
Unfortunately my feeling is that this solution of using gdb is not yet what we need becouse I don't think it's something easy to install (those who tried apparently had to struggle a lot before having a working solution), the dimensions it brings with it, the need to have Phyton ...
After a few years of experience with the GnuCOBOL product, which is now close to version 4, I think we are not there yet.
GIX forces you to use a different IDE, I can't say how complete and reliable it is still
In my opinion we don't have a simple enough debugger yet.
A few years ago a fork called OCEAN (Open Cobol Embedded Animator) appeared which promised just what was needed (a complete written solution of animation just for GnuCOBOL and similar to others ANIMATORS) but then the project was stopped.
Writing a GnuCOBOL debugger is no trivial task. There are User Interface and system control requirements that don't exist in normal business applications programming.
I wish there was something similar to Compuware Xpediter, but for GnuCOBOL (either fixed format or free format) that would also work with GnuCOBOL on Linux or MacOS as well as Windows.
GDB already exists, but it is built to debug the intermediate C code. COBOLWORX tries to solve that with its owl tools. It all "sort of" works, but it is not easy to set up, and takes a fairly long time to learn. The example of Python also suggests that approach uses a lot of machine resources.
I am generally content to use the MinGW32 compilers and throw some display statements in. That works pretty well for batch programs and doesn't require a lot of additional tools or resources.
While that looks like a bit of topic drift: Getting used to GDB (using COBOLworx extensions) did took some time for me, too - but now I'm really very fast with that now. I also have seen that with COBOL-only colleagues that only used Animator before, which tell me that after using it several times they are now faster with GDB (we use a frontend so you don't need to type anything in the gdb command and always see your COBOL code).
Additional GDB brings in a lot of options and external tools leveraging it, for me especially valgrind and rr, and allows easy attach and even remote debugging options.
Note: There are also GDB frontends which don't use the COBOLworx extensions, below them are gnucobol-debug for vscode and (added recently, still "early version") cobgdb which provides an animator-like command line tool. Both possibly also work with the "old" MinGW toolset. Who volunteers to test that?
Last edit: Simon Sobisch 2023-10-24
It is not clear whether you are referring to the test of Oleg's debugger or to the test of the new cobgdb solution.
It is not even clear what the difference is between the two solutions and why .
If Oleg's debugger is working then why is anyone else moving forward with a new debugger like cobgdb ?
My system is Windows 10 and I only use the Mingw version downloaded from Arnold.
However if it is ok, then I am available to proceed with the necessary testing phases.
I believe that your support will be needed at least to set up the test environment.
I'm referring to:
Because of the different user interface and principles. And of course "no software is perfect" (I find that currently both don't work well for "production environments" with hundreds or thousands of modules because of some design issues - but my feeling is that cobgdb gets there faster).
That should work. As both use GDB to interact with the process "under the hood", you needs a working GDB version 6.0+. As far as I know even "old" MinGW (Sept 2013) distributes GDB 7.6.1; newer versions (Aug 2020) provides GDB 9.2.
If it isn't contained you can also use another binary, for example from https://github.com/noword/GDB-Windows-Binaries.
Please check the project's README, those should be clear enough. If not then please contact the poject author, either by creating an issue in their repo or by sending them a mail.
One hint: If using Arnold's build and start with set_env.cmd (vs. system installation), then you'll first close all instances of vscode, then open set_env.cmd and from this command window open vscode (or cobgdb). Whichever version of GDB you use, it should be in PATH and named "gdb" (exe/cmd/bat) to be easily found.
Arnold
I have been trying to run this build, but can not get step 7 or step 8 to run.
I get the message that the required first input parm is missing.
I have tried both to copy and paste, and to type the input. I get the same error either way.
source build-x32.sh | tee build-x32.txt
is what I entered.
Other than the number of processors (cpu_count), I used all defaults. I used NotePad to edit the two files.
This is my first attempt to use one of your builds. The install pdf is very clear in what to do. Im on windows 10 and currently use 3.1.2.0 with no issues. I just wanted to try 3.2 again to see if the problems I have with my virus software still exist.
I Duh Know.
Michael :-)
Make sure you have the name of the script typed correctly, and that you're starting in the right folder and starting in the right MSYS2 component (MSYS2 MINGW32 or MSYS2 MINGW64). Don't start in the MSYS2 task. I tend to set the cpu_count to 1, but that will make the build run longer.
Be sure to include the full command, without the slash, for example:
source build-x32.sh | tee build-x32.txt
or
source build-x64.sh | tee build-x64.txt
And if you're still having problems we can contact Chuck Haatvedt.
.
Arnold
I quadruple checked what and where I was doing the things.
I even deleted and restarted from scratch 3 times.
The error messages are coming from the build sh files.
I Duh know.
Michael :-)
In the meantime you may just use the 3.2 binaries that are available from Arnold's page.