Build gnucobol for mingw32

[GitMensch]

Package name

gnucobol

For which environment do you need the package?

MINGW32

Provide a brief description why you need this package in the selected environment

There are a lot of people using 32bit GnuCOBOL (because of the pointer size embedded in COBOL structures) and as "good old" MinGW gets more and more harder to use it would be good to keep that in MSYS2 as long as there is a mingw32 port. You know... legacy...

~There are currently two dependencies for the gnucobol package which are not available for win32 any more; cjson can be easily swapped to json-c (I'm just making a PR for that -> #22134) as it is just used "under the hood".~ Edit: "only" db left. In any case the dependency package "db" would have to be re-enabled for mingw32 as well, to allow enabling it for the gnucobol package.

Are you willing to submit a PR?

sure, just adding mingw32 back to both packages

[ArnTrembley]

As a user of 32bit MinGW GnuCOBOL I would like to see continued support for 32 bit MinGW and GnuCOBOL.

[Biswa96]

As a user of 32bit MinGW GnuCOBOL

Could you provide the reason for using 32 bit gnucobol?

[ArnTrembley]

I build GnuCOBOL binaries using MinGW32 for anonymous download from my website. I have users who request a 32-bit version of GnuCOBOL for Windows, due to old hardware or Windows versions (XP or Win7). The Chocolatey package manager for Windows uses my 32-bit MinGW GnuCOBOL build for its download. The Chocolatey GnuCOBOL has been downloaded over 4,300 times, and 243 times since it was last updated on 15 May 2024.

Also, when I build a MinGW32 GnuCOBOL binary, the download is only 24 megabytes. When I build an MSYS2 GnuCOBOL binary the download size is about 95 megabytes (even for MSYS2 32-bit builds). For some users the download size is a pain point.

[GitMensch]

But this issue is about MSYS2 MINGW32, so the main point of the above don't apply. Older versions of the operating system are not supported with MSYS2 either, which is one reason to keep providing old mingw builds.

But people moving from the old mingw to the new MSYS2 based builds can simply swap only if they use the 32 bit version as structures used are defined often with fixed lengths, including pointers. Moving to 64 bit means to check all possible occurrences of those as well as checking all possible CALLs into non-COBOL space (verify that 64 bit versions of those also exist)... and means to recompile every COBOL program. Even moving from mingw to MSYS2 doesn't mean any of those are necessary as the ABI to libcob is not changed.