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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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...
@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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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:
cobc
hanging before because of this once (quite some time ago).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.
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.
Short update - that's what I've done to recheck this issue
get pre-requisites:
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 seedouble-click set_env.cmd -> now everything is setup for GC
SUBDIRS = src_c src_cobol src_java
, so that's what we're doingsrc_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 thatcall "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 torem
that lineconst
, I just ignore this and go on (one could suppress it by adding-A -Wno-discarded-qualifiers
to the last compilation)rem
'd thecall
lines now up-front, then execute it from the cmd opened by set_env.cmd, got output of "return status 0" so going onSo 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
thecall
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.
To check what is going on; prefixed the
cobc
call in the-c -free -v -Wno-unfinished cobjapi.cob
withgdb --args
, executed it (halts in gdb as expected) executedrun
there, result: SIGSEGV, as all debugging information is stripped from Arnold's binaries there is no further hint either there or when executing thebt
command - executingquit
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:
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
call
s 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
andCOB_LIBRARY_PATH
?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].
Related
Bugs:
#666Last edit: Simon Sobisch 2020-07-27
@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).
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
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
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.
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...
Simon,
Thank you, I will wait for the update.
Trolley78
@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.
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
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.
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 toC:\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 aimageio.dll
. I looked at the error log and noticed that the process tries to createfileselect.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
Sorry I forgot to attach the files.....
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
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.
Hi Trolley,
I just put cobol on with cygwin. It is really fast process.
thanks,
roboloki
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