Nice to know - have you compiled with -Wadditional as well? That warning is not enabled by default.
Dosbox emulates the beep (interrupt) with a speaker signal, GnuCOBOL will beep if the system provides that functionality. Do you build GnuCOBOL on your own? If not: where do you get it from? For esc and function keys -> see runtime.cfg - you can just add a line without a leading # at the place where you want to have a non-default setting - see ESC and function. You also can try to configure the beep to use a different approach and see which is supported by your environment.
So @stevemackinney - how is your migration project going? Did you stumble over anything where a better support from cobc would be helpful?
If building on a system with recent GCC you'll likely have to adjust CC/CFLAGS - see [bugs:#1214]. That is not different in GC32. If you have that covered and still get errors (and not build with another isam backend than BDB - see the NEWS comment about ISAM edge cases with other backends), then posting the resulting testsuite.log would be useful. And when you checkout a new version from gc3x branch, then yes, you'll currently get 3.3-dev which is much newer with more features and fixes than gc...
As noted we don't want to enforce C99 and some compilers even don't have that option - we'd want to check if the compiler setup as-is does compile the relevant code, and only if not - and no std is given - try to add it: Adding it to default CFLAGS will need a test in configure in any case - so we should first check if the void function declaration and pointer use works or not - and only try to work around that by specifying a std as-needed (and then try gnu17 / c17 / gnu11 /c11 / gnu99 / gnu89 /...
configure and other generated files aren't part of the repository since... GC 1.1 or so. You have two options: 1) build from version control -> after checkout/clone/download execute autogen.sh (creates the additional files, needs more tools - see HACKING for the list); this works with any version (also older ones or "tags") 2) get a nightly tarball (or even binary), the places to look for are https://sourceforge.net/projects/gnucobol/files/gnucobol/nightly_snapshots/ and nowadays also the OCamlPro...
Of course there are hallucinations and missing information in that LLM generated text... there is no libcob.conf but runtime.cfg there is no COB_EBCDIC_OVERRIDE runtime parameter, instead there is the CODE-SET clause in plain COBOL that can be used to do on-the-fly conversion the file part and the general post miss to note the different collating sequence - which again are both possible to explicit code in COBOL (and with GnuCOBOL 3.x+ also possible to pass on the command line / dialect configuration)...
It all depends what license concerns you have (just my understanding, consult your lawyer if the business depends on it): if you use GnuCOBOL only for your in-house software - there's no problem with using AGPL ever, no matter how you use it (it is your code and you are your only customer for that software) if you use it to provide a web frontend to customers then you'd have to make the code ( everything using that) available via that frontend as well - no problem for BDB+GnuCOBOL+dependencies, but...