Issues with MSYS GnuCOBOL Build

[Rich Di Iulio]

Hi All,

As I mentioned in a previous post. I am creating a new topic to discuss my issue.

I was not able to build Cobjapi from the following file; gc31-rc1-vbi-rename-7z-to-exe
I was able to compile the c code, but not cobjapi.cob. I would get cobc.exe stop working and I would have to close the executable.

Then I moved to the instructions from "GnuCOBOL 3.1-rc1 {30JUN2020] Build Guide for MinGW.
I installed Ncurses 6.2 instead of PDCurses. I got the same results in trying to compile Cobjapi.

I will try setting up the Msys64 tomorrow.

I had at one time, compiled GnuCOBOL using Visual Studio on Windows 7 Pro. I tried doing the same thing with Windows 10, but had some issues. My goal is to get a version of the compiler working on Windows 10 and using Cobjapi.

Any thoughts or ideas?

Trolley78

[Simon Sobisch]

I should be able to try to do the cobjapi build using Arnold's build today and will report back after.

Just to recheck some things:

• Did you tried without any security product enabled? I've seen a cobc hanging before because of this once (quite some time ago).
• What version of JDK do you use? [Should only be relevant to the C build and the runtime, but still].

PDCurses/NCurses should not make any difference to the building with cobc as long as you don't need to link curses functions in, which is not the case here.

[Rich Di Iulio]

Simon,

I have the latest Norton 360 running and it did not complain when I was building.

As far as Java, I am using JRE 1.8.0_261 for Windows.

[Simon Sobisch]

Short update - that's what I've done to recheck this issue

get pre-requisites:

• download GC31-rc1-VBI from Arnold and unpack it somewhere
• checkout (download would also work) https://svn.code.sf.net/p/gnucobol/contrib/trunk/tools/cobjapi/SWING

• checking for a matching java version: java --version shows a 64bit environment (I've installed a 64bit version of Java 11 from https://github.com/ojdkbuild/ojdkbuild/releases/), so possibly won't work, we'll see

• double-click set_env.cmd -> now everything is setup for GC

• inspected the Makefile which says SUBDIRS = src_c src_cobol src_java, so that's what we're doing
• found src_c\win_mingw_compile_src_c.bat so executed that from the command prompt started from set_env.cmd, error message, then C compiler warning - better inspect that
  • checked the bat file and found the reason for the error message: call "C:\GC22\GC22B-64bit\bin\cobenv.cmd" - luckily I don't have that PATH here, for now just ignoring the error message for now, but you may want to rem that line
  • checked further - next are the C compiles, actually find that the warning message is ... just a warning message because of a missing const, I just ignore this and go on (one could suppress it by adding -A -Wno-discarded-qualifiers to the last compilation)
• src_cobol - rem'd the call lines now up-front, then execute it from the cmd opened by set_env.cmd, got output of "return status 0" so going on
• src_java: no win script, so checked the Makefile - it only does a copy and the target already exists, so did nothing here

So as everything seems to be there, going on to the examples, the first not simple one is color picker, which also has win_mingw_compile_colorpicker.bat, executing in the set_env.cmd created cmd-window after rem the call

• recompiles the C part, seems strange
• results in an error message "colorpicker.cob: cobc: cobjapi.o: No such file or directory"
• set "verbose=-v", rerun the bat file, shows that cobjapi stops after translation, doesn't even get an error message, ... rechecked the original source_cob, same issue

... so checking that next.

[Simon Sobisch]

To check what is going on; prefixed the cobc call in the -c -free -v -Wno-unfinished cobjapi.cob with gdb --args, executed it (halts in gdb as expected) executed run there, result: SIGSEGV, as all debugging information is stripped from Arnold's binaries there is no further hint either there or when executing the bt command - executing quit and re-did this call with the "GC31-rc1-G-BDB" package from Arnold (which has those debug information still in, but is ~40MB bigger in total and guessed ~1% slower).
... works ?!?, retested without gdb and the "GC31-rc1-BDB" package, breaks (also with GDB).

Retesting with the MSYS2 pre-built and re-packaged package from Arnold.... works both with the M32 and M64 version.
Rechecked also older versions - the stripped "dev" ones also break, the last stripped ones that completes are the old GC30XRC1.

... so as I had a MinGW environment setup before: retried the self-build part and also got a failing, now with access to the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
__chkstk_ms () at ../../../src/gcc-6.3.0/libgcc/config/i386/cygwin.S:178
178     ../../../src/gcc-6.3.0/libgcc/config/i386/cygwin.S: No such file or directory.
(gdb) bt
#0  __chkstk_ms () at ../../../src/gcc-6.3.0/libgcc/config/i386/cygwin.S:178
#1  0x0047db3e in codegen ()
#2  0x0047ee34 in codegen ()
#3  0x0047ee34 in codegen ()
...
#195 0x0047ee34 in codegen ()
#196 0x0047ee34 in codegen ()
#197 0x0047ee34 in codegen ()
#198 0x00493cc2 in main ()

So we now do know that there's an issue in cobc, I'll track that down, likely today. Until then: either use the M32/M64 packages from Arnold or the G-BDB package as those - for whatever heisenbug reason - do compile cobjapi.cob.

... and when you use the windows batches to compile cobjapi: either replace all those calls in their headers or place a wrapper cmd in that (then wrong-named) path that calls the correct set_env.cmd script.

@laszloerdos: Do you see a reason to keep those calls in? If you want them maybe moving it out to a "local_set_env.cmd" that is in the root directories (AWT+SWING) so that there's only one place to adjust it (same for msvc)?
Can you please adjust the windows compile batches to do the same as the Makefile - using the pre-built object files instead of compiling them again? ... and was there a reason to no create cobjapi.so / dll which has cobjapi.cob + all c object sources in, then using that via COB_PRE_LOAD and COB_LIBRARY_PATH?

[Simon Sobisch]

Update: found the "reproduce reason": the issue is -finline-functions together with -O2, if I remove one of those from CFLAGS the SIGSEGV does not occur on this setup any more...

Tracked under [bugs:#666].

[Simon Sobisch]

@trolley78 If you grab the newest tarball from the nightly builds and use this for updating your mingw build environment you should be able to use the fix (actually it is more like a workaround for a bug in an older GCC version, but the refactor result is cleaner in any case); otherwise you'd need to wait for Arnold's next builds, possibly not earlier than rc2 (sometime in August 2020).

[Rich Di Iulio]

Simon,

Thank you for looking at this problem. I did not quite understand the process you went through. I am not sure if you had a problem compiling cobjapi.cob program.

I am not as familiar with the website and all the workings as I would like. I do not know where to find the latest Nightly Build you referenced.

Again Thanks.

Trolley78

[Rich Di Iulio]

Hi All,

I downloaded what I thought was a nightly build, r3740. I still cannot compile cobjapi.cob.
I also download the latest 3.1-dev and had the same problem. So I need help please on getting a Windows solution for GnuCOBOL.

Has anyone been successful in getting Visual Studio 2015 or 2017 to build GnuCOBOL?

Any help would be very much appreciated.

Trolley78

[Arnold Trembley]

When I look at the nightly builds, the tar.xz and tar.gz files contain internal dates of 2020-07-26, which implies the nightly build tarballs were last created for r3737, and therefore wouldn't have the cobc recursion fix in r3738 or r3740.

I know it's possible to check out from SVN, but I don't know how to convert that into a tarball.

[Simon Sobisch]

The nightly builds also have a build history, linked in the rendered README, which shows that there's a failing in one of the environments which looks quite bad so you may want someone (in that case me) to fix it before using it.
The link to "whatever commit was without an issue" likely shows the last revision where everything worked which is, according to the build history, r3737.

For now you should be able to at least get the full tarball for the newer versions by going from the build history to the "green" environment, then to artifacts, then to the tarball. Deep link to the one from r3739: https://ci.appveyor.com/project/GitMensch/gnucobol-3-x/builds/34350695/job/ajyu5bul9mw00kgw/artifacts - building from there should produce a version that works, but there's likely a reason for the failure so I should inspect that sooner than later and you may want to wait for that...

[Rich Di Iulio]

Simon,

Thank you, I will wait for the update.

Trolley78

[Simon Sobisch]

@trolley78 can you please verify if cobjapi works fine with the current snapshot? I expect it to do so but haven't tested it yet.

[Rich Di Iulio]

Simon,

I pulled the latest snapshot the other day R3892-TRUNK. However, there was no configure file. I will have to look again for a different snapshot. I am build GnuCOBOL from scratch using the instructions from Arnold Trembley. The MSYS2 64-Bit. Is this what your expecting?

Trolley78

[Simon Sobisch]

Sorry I should have been more clear. I've asked to get the current CI produced snapshot of 3.x and try with this one. It is a complete tarball very similar to the one that is uploaded as a release tarball.
As a short-cut you may also use the pre-built MinGW environment which should be useable very similar to Arnold's builds, if the download size doesn't matter.

[Rich Di Iulio]

Okay Simon, I built the MSYS2 64Bit environment according to Arnold Trembley instructions. I then did this pacman -S mingw-w64-x86_64-gnucobol, which installed GnuCOBOL. Finished the instruction and copied FILES to C:\GC\GC31-RC2 Compile Cobjapi with no problems. I was able to compile my main programs, but not my sub-programs. When I compile programs, I capture the output to a file. I noticed that the compile process creates a imageio.dll. I looked at the error log and noticed that the process tries to create fileselect.dll & japilib.dll, but does not. I decided to try and build them directly. They fail and I get the same output that is in the sub-program error file. I have included the error file for further investigation. When I build my programs under Linux, this works just fine. This might help, the DLLs are created as SOs.

Then I tried to build the snapshot from the link you presented me. I am able to run configure, but make fails. I cut and pasted the end of the build into a file (MAKE.ERR).

if there something I am doing wrong please let me know. I am flying a little blind.

Trolley78

[Rich Di Iulio]

Sorry I forgot to attach the files.....

[Rich Di Iulio]

Hi All!

After re-reading this thread and other threads, I was wondering if I could override CFLAGS? If yes, how would I do that? Thank you.

Trolley78

[Simon Sobisch]

That depends on the context that is missing here (I'm reading via mail currently).
If you want to add this when running configure then just specify it after the other options.
If you want to change it when self building then do the same in the package definition (obviously you cannot change the flags for the GnuCOBOL build after it was build).

You can change cobc's default, inspect it by cobc --info and take the one it mentions and export/set it as you want.

[alien with special powers]

Hi Trolley,

I just put cobol on with cygwin. It is really fast process.

thanks,
roboloki

[Rich Di Iulio]

roboloki,

I am not interested in using cygwin. I am using mingw. The work I am doing is cross-platform, using Windows 10 (mingw) and Linux Mint 20.

Thank you for the reply.

Trolley78