winlibs.com

[Brian Tiffin]

Has anyone tried the GNU Compiler Collection on Windows from the winlibs.com bundles?

This might ease some of the griefs, or add more, as I can't really try this from here in getting people comfortable with GnuCOBOL on Windows and building from sources.

https://winlibs.com/

I guess I'll poke @sf-mensch and @arn79, and perhaps @marcoridoni with the question too.

Curious,
Blue

[David Wall]

With respect Brian - What 'griefs' are there in building from sources ??.

I've built from source for the last 4 years using Mingw using originally the Guide put out by Arnold T & more recently setting up my own scripts to automate it.

I 'did' have a gander at the winlibs site but was more confused than ever I have been.
Also - I didn't see GnuCOBOL mentioned once on their website. ???

[Brian Tiffin]

Oh, I may have misspoke, David, seeing as I've never had any of the grief, but we have taken heat regarding building GnuCOBOL from source on Windows for over a decade now. Arnold put together the click click installer and a lot of that went away. But that is not developers building from source, it's developers click click installing the compiler.

First time I tried on Windows, I just used Cygwin, and it worked...but I had a leg up in that I had a few clues of what would need to installed via the Cygwin setup package manager before I tried it. But, the Cygwin angle came with a boat load of hassles when it comes to redistribution. By the time I was hearing about it, I had no more Windows on any work nodes to try things here, and Arnold stepped up and saved the day. ;-)

GnuCOBOL improves in waves and dribbles. I was thinking that a well thought out command line gcc from a Windows console might help dribble in some future.

Cheers,
Blue

[Arnold Trembley]

Brian,
This is the first time I've heard of winlibs.com. I spent over an hour following links and reading. It sounds like there are a lot of good tools there. If you're suggesting that Windows builds of GnuCOBOL could be converted from MinGW (either old or new MSYS2 MinGW 64-bit) to Winlibs GCC, it sounds like it would be possible to do, and would likely have some benefits. But I wouldn't know where to begin because I am not a C/C++ coder.

There's a lot of interesting stuff there, particularly on UCRT.

Winlibs would also be a good tool for doing any kind of C/C++ development on Windows where you want to use an open-source compiler, based on GCC, with fewer dependencies on Windows versions and Microsoft C Runtime library versions.

Thanks!

[Brian Tiffin]

Thanks to you, Arnold. :-)

I found out about winlibs.com from an off the cuff remark by one the moderators in the V programming language Discord channel, and thought I'd pass it along.

Have good,
Blue

[Simon Sobisch]

From a quick view this likely is useful for some people - but for the most it would be more reasonable to just use the basis of most of this: MSYS2. @arnold: yes - ucrt could be quite useful for the people that target Win10+, but this could lead to conflicts with proprietary tools like DB2 libs that are build against MSVC runtime (I don't know).
If we only see usefulness in this, then it would be reasonable to create the MSYS2 packages from the ucrt environment (UCRT64GCC + UCRT32/64CLANG is also available with MSYS2).

So far I didn't spot anything that would speak for winlibs when comparing with MSYS2.
And for everything "older" (I'm quite sure the winlibs stuff as MSYS2 needs at least Win7, ucrt needs at least Win10 in any case) the "old" MinGW (which is still updating; last time I've check it was on GDB and GCC 9.2) is the way to go.

[Arnold Trembley]

They way I read it, UCRT (Universal C Run Time) is included in Windows 10, but available as a free download for Vista, Win7, and Win 8.1. There will also be a redistributable UCRT for Windows XP. The olderMSVCRT (Microsoft Visual C++ Run Time) would still be included, but it comes in different versions depending on Windows OS version and Visual Studio version.

Here are some links and quotes:

"Traditionally the MinGW-w64 compiler used MSVCRT as runtime library, which is available on all versions of Windows."

"Since Windows 10 Universal C Runtime (UCRT) is available as an alternative to MSVCRT. Universal C Runtime can also be installed on earlier versions of Windows (see: Update for Universal C Runtime in Windows)."

https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c

https://docs.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-160

"Because the UCRT is now a Microsoft Windows operating system component, it is included as part of the operating system in Windows 10 and later. It's available through Windows Update for older operating systems, Windows Vista through Windows 8.1. A redistributable version is available for Windows XP. As an operating system component, UCRT updates and servicing are managed by Windows Update independently of Visual Studio and Microsoft C++ compiler versions. Because the UCRT is a Windows component, for security and ease of updates, and a smaller image size, we strongly recommend central deployment of the UCRT for your app."

"Many functions were added or updated in the UCRT to improve ISO C99 conformance, and to address code quality and security issues. In some cases, this required breaking changes to the library. If your code compiled cleanly when using an older version of the CRT but breaks when compiled using the UCRT, you must change your code to take advantage of these updates and features. For a detailed listing of the breaking changes and updates to the CRT found in the Universal CRT, see the C Runtime Library (CRT) section of the Visual C++ change history. It includes a list of affected headers and functions that you can use to identify the changes needed in your code."

(end of quotes)

Winlibs is 64-bit only and uses MSYS2 and GCC. Winlibs can be configured to build for UCRT or VCRT.

I will continue to build GnuCOBOL binaries using the older 32-bit MinGW. It's convenient and the GnuCOBOL compiler folder is smaller. The compiler and generated executables also run in 64-bit Windows.

There is a package for building GnuCOBOL on Windows using MSYS2/MinGW-64bit. Like the older MinGW, it only builds for MSVCRT rather than UCRT.

It sounds like something to think about. Maybe at some point in the future, MSYS2/MinGW-64bit will also have an option to build for UCRT.

Kind regards,

[Simon Sobisch]

You are correct - ucrt should also work with older environments (may need a manual install), I've missed that before.
But MYS2 based packages (which would also be the case for winlibs as far as I see) won't. https://www.msys2.org/ says:

MSYS2 requires 64 bit Windows 7 or newer

The 32bit packages should also work fine on 32bit versions (you just can't install/update those with msys2, but "re-packaged" is fine).

There is a package for building GnuCOBOL on Windows using MSYS2/MinGW-64bit. Like the older MinGW, it only builds for MSVCRT rather than UCRT.

No. As seen in https://www.msys2.org/docs/environments/ There are much more environments, including UCRT (gcc64 + clang32 + clang64).

To get the ucrt packages:

• as always: start MSYS2 environment, run pacman -Syu (likely with at least one necessary restart of MSYS2 environment) until it says "Everything is up to date" (if you have an "older" installation it will update pacman and also include the new package repositories)
• adjust the repo list notepad.exe /etc/pacman.conf to include/remove what you like, if you want a clang32environment then copy the clang64 one and use 32 in that
• install GnuCOBOL and all its dependencies for the the environments you like, here for all UCRT environments but ARM:
  pacman -S mingw-w64-ucrt-x86_64-gnucobol mingw-w64-clang-x86_64-gnucobol mingw-w64-clang-i686-gnucobol
• do your packaging as always - now just from the ucrt64 / clang32 / ... folders instead of mingw64

In the process you also get a ucrt64.exe and similar, which you may use for opening a shell environment locally.

[Simon Sobisch]

Now tested - works as expected.

While checking if/how that works, did finally bring cobenv.cmd up-to date (for now not published, will be done with the 3.2rc1 https://github.com/msys2/MINGW-packages/compare/master...GitMensch:patch-2 - so you may want to manually copy that in) and adjusted the MSYS2 docs - https://github.com/msys2/msys2.github.io/pull/176 ...

End result: After the suggested pacman -S mingw-w64-ucrt-x86_64-gnucobol There's a ucrt64 folder which can be used as a package base, and with the adjusted cobenv.cmd double-clicked you get

GnuCOBOL developer prompt

GnuCOBOL 3.1.2 (Apr 04 2021 12:56:54), (MinGW) "10.2.0"
GMP 6.2.1, libxml2 2.9.10, cJSON 1.7.14, ncursesw 6.2.20200212, BDB 6.0.19

D:\GnuCOBOL-3.1.2\ucrt64\bin>

[Arnold Trembley]

Thanks very much!

I have downloaded the complete revised file cobenv.cmd, and I will look for the 64bit MinGW UCRT GnuCOBOL build package, hopefully in the near future.

[Ralph Linkletter]

So are you going to do another build with UCRT ?
To what purpose other than it was "discovered" recently ?
I think it will only add more confusion for Windows users.
Especially those users that are doing DB/2 or CICS or zOS simulation in general.
Is this UCRT based GnuCOBOL really necessary or is it of the "let's play with this" ilk.
On Jan 14, 2022 I can still count on one hand the number of 64 bit professionally deployed COBOL applications.

Ralph

[Simon Sobisch]

To what purpose other than it was "discovered" recently ?

The documentation suggests that UCRT builds will have a better compatibility to DLLs generated by Microsoft's recent C compilers and may be faster / more secure.