Well, progress, guess I got path or install wrong, but this is where it landed:
mickeyw@mickeyw-Meerkat:~/gnuCobol2.2/gnucobol-2.2/cobc$ ./cobc --version cobc (GnuCOBOL) 2.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart Built Sep 06 2017 20:28:07
Packaged Sep 06 2017 18:48:43 UTC
C version "5.4.0 20160609"
mickeyw@mickeyw-Meerkat:~/gnuCobol2.2/gnucobol-2.2/cobc$
will look tomorrow...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried building with MinGW, and it shows packaged as july 20 (the RC-1 date):
cobc (GnuCOBOL) 2.2-rc.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Sep 07 2017 01:45:53
Packaged Jul 20 2017 20:13:05 UTC
C version "6.3.0"
I used the tar.xz file
Also, make check had two tests tail with a windows message box:
14: Run job after compilation FAILED (used_binaries.at:434)
15: Run job with optional arguments FAILED (used_binaries.at:456)
The message box said:
The procedure entry point cob_module_global_enter could not
be located in the dynamic link library libcob4-dll.
I will have to try rebuilding on Friday. I don't think I pulled in the Release candidate version, but I could be wrong. It's pretty late for me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where have you seen cobc (GnuCOBOL) 2.2-rc.0? I assume you either have not run make install or it did't reported a successeful installation (depending on your install this may need an MSYS shell started with "run as admin").
The message boxes show: You have a libcob version in PATH that is the July version (either within your MSYS/MinGW installation or in general, once setxed).
Note: The testsuite should work in this situation nonetheless. atlocal (sourced by the testsuite) prefixes the PATH variable, I assume this is only taken into account for the first programm run (in this case cobc.exe), but is not shared with the processes that are started from cobc (which is the case for "run job -j). This normally only happens when the two processes were linked against different C runtime libraries - which shouldn't be the case...
You can verify this by rerunning one of these tests make test TESTSUITEFLAGS=14, wait until the message pops up, investigate the environment of both the starting cobc process and the process it tries to start - I'd suggest to use Sysinternals Process Explorer for this as it allows you to order the processes in tree (=you can easily see which process was started from what) and inspect the process environment.
Simon
Last edit: Simon Sobisch 2017-09-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm pretty sure I corrupted my MinGW folder. I'm going to erase it and start from scratch. It will probably be late Friday or Saturday before I finish my next build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I rebuilt my MinGW environment with the most current version of MinGW and MSYS, including GCC 6.3.0.
There were some unexpected problems during the build. The configure step for Berkeley DataBase failed with the following error, but simply rerunning the configure appeared to solve the problem:
"checking size of int... rm: cannot lstat `conftest.exe': Permission denied"
I still need to build VBISAM and NODB versions of GnuCOBOL 2.2 (06SEP2017) and post them, along with updated PDF and ODT versions of by MinGW Build GC22 guide. That should happen within the next day or two.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There were some unexpected problems during the build.
Nearly all of these go down to some process locking/checking/whatever the files. We had this discussed multiple times here (someone should create a wiki entry for this we can point to), the reasons normally are:
Windows (or other) Indexing service, solution: build in a folder that is explicit removed from indexing or deactivate indexing as long as building the environment
Security suite, solution: build in a folder that is explicit removed from indexing or deactivate the suite as long as building the environment (reactivate later!)
Windows Application Experience Service, solution: deactivate the service as long as building the environment (not sure if it is possible to exclude a folder [it is possible to exclude single executables, but normally only manually]) - Note: As people reported issues that occured only if this service is disabled - only disable this when you have issues after taking care of the two previous ones (side note: I personally had never any issues with this and didn't need to disable the service on any machine)
In general it should work out of the box in the testsuites (both internal and NIST) without any of those changes (but with those changes you'll likely see a speed-up of the process), same is true for the build part.
For configure: We really should discuss with the autoconf team to change "conftest" to "conftest-timestamp-or-other-random-number" as this created issues for a lot of projects in the last 8 years...
In general: Thank you for the builds, I think about removing it from my todo list (I would have created the official build this weekend otherwise) - What do all of you think about this?
Last edit: Simon Sobisch 2017-09-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon,
I will have to look into Windows (or other) indexing service. When you say "Security Suite", I assume you mean Antivirus, etc. On my usual development Windows PC it is McAfee Internet Security. On my refurbished laptops it is either MSE/Windows Defender (for Windows 10), or Avast freeware Anti-virus. Deactivating Windows Application Experience Service I would probably try last, since you report deactivating WAES doesn't seem necessary.
I had none of those problems running "make", "make check", or "make test" on GC 2.2.
As always, thank you very much for all your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I turned off McAfee Internet Security (but left Windows Defender on) and that got rid of all the "permission denied" errors.
The build of GnuCOBOL 2.2 with VBISAM 2.01 ran flawlessly, with the same test results as with BDB. So I have two pre-built MinGW versions available for download:
I still need to built a "NODB" version with no indexed access support, and do a final update before publishing my MinGW build guide in PDF and ODT formats.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Arndold. I removed all my Cygwin64 files and loaded your gc22BDB and hooked it to the opencobol ide and reset my paths and works great. This will be my Windows Cobol project and I have already installed the new gc22 on my Ubuntu box. All is well !
You guys Rock !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simon, this is on my linux box. I did the install of the 2.2RC version back in July. And last night did the newer 2.2 release....
I will investigate the environment tonight when I get home. Thanks for the help.
I am thinking now that the /usr/local/bin/cobc is where the new version should be, perhaps the permissions are wrong. Not sure on all there is about sudo... yet !
I do need to clean up my installs on the meerkat (Ubuntu) linux box. And I will try the install on my windows box either tonight or next.
Thanks Again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On your linux box: just sudo the make install part. If you forget the sudo the make install should have reported a failure, did not installed anything and therefore cobc --version still shows the old info.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well mystery solved. When I installed the first time I thought doing make check and make test was all to do. (Did not read ALL of the instructions) I did the make install (as sudo) and it works great now.... THANKS Simon. Now summer is almost gone, I can devote more time to this !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Manuals including Programmers Guide, Quick Reference and the Sample Programs have been issued for v2.2 Final release and are now on SF under code / external docs with the .pdf files in the PDF directory.
Updated copies as usual are also at :
applewood.dtdns.net/files/GnuCobol/
Short names are linked to the full file names (within Linux) so both work depending on your preferences.
If errors or ommitions are spotted please report in the bug tracker under Programmers Guide tag for v2.2.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attached are test reports from the installation of the latest version of GnuCOBOL 2.2 with MinGW-GCC 3.4.5, TDM-GCC 4.8.1, and MinGW-GCC 5.3.0. The only serious problem is that 'make test' still aborts abormally in GCC 5.3.0 (see att.)
For installation instructions, you can also try the mingw_msys_install_guide or (for Linux) vbisam_install_guide_v5.1:
the only serious problem is that 'make test' still aborts abormally in GCC 5.3.0 (see att.)
The attachement has for the internal testsuite:
:
756 tests behaved as expected.
... and shows no "abnormally abort" but a failing test in the IX module of NIST test. Which it doesn't on my installations of MinGW. But the build in question uses VB-ISAM (which works on GNU/Linux) and therefore I guess it is a VB-ISAM (with the version you've used) windows (or even MinGW) specific issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reported the IX errors with both the msys folder from the MinGW installer and the msys+7za+wget+svn+git+mercurial+cvs-rev13.7z build, so it's probably not an MSYS issue.
In the att. on the present thread, the IX errors do not occur in MinGW-GCC 3.4.5 or TDM-GCC 4.8.1 (both with VBISAM), so it's probably not a VBISAM issue.
I reported the same IX errors with Knoppix 7.6.1, so it's not a Windows-specific issue.
The IX errors do not occur in earlier GCC's in MinGW or Linux (such as Linux Mint 10). They do occur in Win7 x64 MinGW 5.3.0 and Knoppix 7.6.1 GCC 5.2.1. That's why I'm guessing that the error is related to GCC 5.x.
Anon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
using the procedure in the MinGW/MSYS Installation Guide gives the same result as GCC 3.4.5 and GCC 4.8.1. Only GCC 5.x (GCC 5.3.0 in Win7, GCC 5.2.1 in Knoppix 7.6) gives the abnormal makefile abort.
The older GCC's are better for making builds for older OS's. They are probably also better for a longterm project like GnuCOBOL that includes older code. (Why use a GCC compiler from 2017 to compile code written in 2007?)
Anon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the GCC 6.3.0 build, I initially got the same "Permission denied" error that Arnold did. I did not report the error because I thought I had made a typo. I just re-typed the entire ./configure and it ran.
My build did not use the MinGW installer -- instead I followed the MinGW/MSYS Installation Guide.
The error did not occur in any of the builds with earlier GCC's. The config logs from all of the previous builds are attached so that maybe you can determine the cause of the problem.
Got notice of the new 2.2 version posted. Downloaded and installed: All test passed but is this really the correct version?
Well, progress, guess I got path or install wrong, but this is where it landed:
mickeyw@mickeyw-Meerkat:~/gnuCobol2.2/gnucobol-2.2/cobc$ ./cobc --version
cobc (GnuCOBOL) 2.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Sep 06 2017 20:28:07
Packaged Sep 06 2017 18:48:43 UTC
C version "5.4.0 20160609"
mickeyw@mickeyw-Meerkat:~/gnuCobol2.2/gnucobol-2.2/cobc$
will look tomorrow...
I tried building with MinGW, and it shows packaged as july 20 (the RC-1 date):
cobc (GnuCOBOL) 2.2-rc.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Sep 07 2017 01:45:53
Packaged Jul 20 2017 20:13:05 UTC
C version "6.3.0"
I used the tar.xz file
Also, make check had two tests tail with a windows message box:
14: Run job after compilation FAILED (used_binaries.at:434)
15: Run job with optional arguments FAILED (used_binaries.at:456)
The message box said:
The procedure entry point cob_module_global_enter could not
be located in the dynamic link library libcob4-dll.
I will have to try rebuilding on Friday. I don't think I pulled in the Release candidate version, but I could be wrong. It's pretty late for me.
Where have you seen
cobc (GnuCOBOL) 2.2-rc.0? I assume you either have not runmake installor it did't reported a successeful installation (depending on your install this may need an MSYS shell started with "run as admin").The message boxes show: You have a libcob version in
PATHthat is the July version (either within your MSYS/MinGW installation or in general, oncesetxed).Note: The testsuite should work in this situation nonetheless.
atlocal(sourced by the testsuite) prefixes thePATHvariable, I assume this is only taken into account for the first programm run (in this casecobc.exe), but is not shared with the processes that are started fromcobc(which is the case for "run job-j). This normally only happens when the two processes were linked against different C runtime libraries - which shouldn't be the case...You can verify this by rerunning one of these tests
make test TESTSUITEFLAGS=14, wait until the message pops up, investigate the environment of both the startingcobcprocess and the process it tries to start - I'd suggest to use Sysinternals Process Explorer for this as it allows you to order the processes in tree (=you can easily see which process was started from what) and inspect the process environment.Simon
Last edit: Simon Sobisch 2017-09-07
I'm pretty sure I corrupted my MinGW folder. I'm going to erase it and start from scratch. It will probably be late Friday or Saturday before I finish my next build.
I rebuilt my MinGW environment with the most current version of MinGW and MSYS, including GCC 6.3.0.
There were some unexpected problems during the build. The configure step for Berkeley DataBase failed with the following error, but simply rerunning the configure appeared to solve the problem:
"checking size of int... rm: cannot lstat `conftest.exe': Permission denied"
Then BDB make failed with the following error:
libtool: install: ranlib /mingw/lib/libdb.a
C:\GC22-Build\MinGw\bin\ranlib.exe: unable to rename 'C:/GC22-Build/MinGw/lib/libdb.a'; reason: File exists
make: *** [install_lib] Error 1
Rerunning the make step appeared to solve that problem.
There were similar errors in the GnuCOBOL 2.2 (06SEP2017) configure:
rm: cannot lstat
conftest.exe': Permission denied checking for dlopen in -lc... rm: cannot lstatconftest.exe': Permission deniedrm: cannot lstat `conftest.exe': Permission denied
I reran the configure and continued.
The "make", "make check", and "make test" steps ran very smoothly.
Here are the "make check" results:
The summary.log for the "make test" NIST COBOL85 testsuite also looked good:
And the compiler appears to work fine:
You should be able to download it from here:
http://www.arnoldtrembley.com/GC22-BDB-rename-7z-to-exe.7z
I still need to build VBISAM and NODB versions of GnuCOBOL 2.2 (06SEP2017) and post them, along with updated PDF and ODT versions of by MinGW Build GC22 guide. That should happen within the next day or two.
Nearly all of these go down to some process locking/checking/whatever the files. We had this discussed multiple times here (someone should create a wiki entry for this we can point to), the reasons normally are:
In general it should work out of the box in the testsuites (both internal and NIST) without any of those changes (but with those changes you'll likely see a speed-up of the process), same is true for the build part.
For configure: We really should discuss with the autoconf team to change "conftest" to "conftest-timestamp-or-other-random-number" as this created issues for a lot of projects in the last 8 years...
In general: Thank you for the builds, I think about removing it from my todo list (I would have created the official build this weekend otherwise) - What do all of you think about this?
Last edit: Simon Sobisch 2017-09-08
Simon,
I will have to look into Windows (or other) indexing service. When you say "Security Suite", I assume you mean Antivirus, etc. On my usual development Windows PC it is McAfee Internet Security. On my refurbished laptops it is either MSE/Windows Defender (for Windows 10), or Avast freeware Anti-virus. Deactivating Windows Application Experience Service I would probably try last, since you report deactivating WAES doesn't seem necessary.
I had none of those problems running "make", "make check", or "make test" on GC 2.2.
As always, thank you very much for all your help!
I turned off McAfee Internet Security (but left Windows Defender on) and that got rid of all the "permission denied" errors.
The build of GnuCOBOL 2.2 with VBISAM 2.01 ran flawlessly, with the same test results as with BDB. So I have two pre-built MinGW versions available for download:
http://www.arnoldtrembley.com/GC22-BDB-rename-7z-to-exe.7z
http://www.arnoldtrembley.com/GC22-VBI-rename-7z-to-exe.7z
I still need to built a "NODB" version with no indexed access support, and do a final update before publishing my MinGW build guide in PDF and ODT formats.
Thanks Arndold. I removed all my Cygwin64 files and loaded your gc22BDB and hooked it to the opencobol ide and reset my paths and works great. This will be my Windows Cobol project and I have already installed the new gc22 on my Ubuntu box. All is well !
You guys Rock !
View and moderate all "Help getting started" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thank you Arnold. Your pre-builds rock :)
Steve
Simon, this is on my linux box. I did the install of the 2.2RC version back in July. And last night did the newer 2.2 release....
I will investigate the environment tonight when I get home. Thanks for the help.
I am thinking now that the /usr/local/bin/cobc is where the new version should be, perhaps the permissions are wrong. Not sure on all there is about sudo... yet !
I do need to clean up my installs on the meerkat (Ubuntu) linux box. And I will try the install on my windows box either tonight or next.
Thanks Again.
On your linux box: just
sudothemake installpart. If you forget thesudothemake installshould have reported a failure, did not installed anything and thereforecobc --versionstill shows the old info.Well mystery solved. When I installed the first time I thought doing make check and make test was all to do. (Did not read ALL of the instructions) I did the make install (as sudo) and it works great now.... THANKS Simon. Now summer is almost gone, I can devote more time to this !
Manuals including Programmers Guide, Quick Reference and the Sample Programs have been issued for v2.2 Final release and are now on SF under code / external docs with the .pdf files in the PDF directory.
Updated copies as usual are also at :
applewood.dtdns.net/files/GnuCobol/
Short names are linked to the full file names (within Linux) so both work depending on your preferences.
If errors or ommitions are spotted please report in the bug tracker under Programmers Guide tag for v2.2.
View and moderate all "Help getting started" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Attached are test reports from the installation of the latest version of GnuCOBOL 2.2 with MinGW-GCC 3.4.5, TDM-GCC 4.8.1, and MinGW-GCC 5.3.0. The only serious problem is that 'make test' still aborts abormally in GCC 5.3.0 (see att.)
For installation instructions, you can also try the mingw_msys_install_guide or (for Linux) vbisam_install_guide_v5.1:
https://sourceforge.net/p/open-cobol/discussion/help/thread/7dfebf0e/ (post 2017-08-03)
https://sourceforge.net/p/open-cobol/discussion/help/thread/13da330d/ (post 2017-07-30)
However, I think that Simon has solved the OP's problem. You're just displaying info from a previous installation.
Anon
The attachement has for the internal testsuite:
:
... and shows no "abnormally abort" but a failing test in the IX module of NIST test. Which it doesn't on my installations of MinGW. But the build in question uses VB-ISAM (which works on GNU/Linux) and therefore I guess it is a VB-ISAM (with the version you've used) windows (or even MinGW) specific issue.
View and moderate all "Help getting started" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Simon,
I call the error an "abnormal abort" because of the makefile errors in the screenshot.
At the end of the thread below (post 2017-08-03)
https://sourceforge.net/p/open-cobol/discussion/help/thread/13da330d/
I reported the IX errors with both the msys folder from the MinGW installer and the msys+7za+wget+svn+git+mercurial+cvs-rev13.7z build, so it's probably not an MSYS issue.
In the att. on the present thread, the IX errors do not occur in MinGW-GCC 3.4.5 or TDM-GCC 4.8.1 (both with VBISAM), so it's probably not a VBISAM issue.
In the thread below (post 2017-07-11)
https://sourceforge.net/p/open-cobol/discussion/help/thread/51d48303/?page=3
I reported the same IX errors with Knoppix 7.6.1, so it's not a Windows-specific issue.
The IX errors do not occur in earlier GCC's in MinGW or Linux (such as Linux Mint 10). They do occur in Win7 x64 MinGW 5.3.0 and Knoppix 7.6.1 GCC 5.2.1. That's why I'm guessing that the error is related to GCC 5.x.
Anon
What do you think about testing a newer GCC version?
View and moderate all "Help getting started" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
GCC 6.3.0 built on Win7 x64 with these packages
gcc-c++-6.3.0-1-mingw32-bin.tar.xz
gcc-core-6.3.0-1-mingw32-bin.tar.xz
libgcc-6.3.0-1-mingw32-dll-1.tar.xz
libssp-6.3.0-1-mingw32-dll-0.tar.xz
libstdc++-6.3.0-1-mingw32-dll-6.tar.xz
libgmp-5.0.1-1-msys-1.0.13-dll-10.tar.lzma
libmpc-1.0.3-1-mingw32-dll-3.tar.xz
libmpfr-3.1.5-1-mingw32-dll-4.tar.xz
mingwrt-5.0.1-mingw32-dev.tar.xz
mingwrt-5.0.1-mingw32-dll.tar.xz
w32api-5.0.1-mingw32-dev.tar.xz
binutils-2.28-1-mingw32-bin.tar.xz
using the procedure in the MinGW/MSYS Installation Guide gives the same result as GCC 3.4.5 and GCC 4.8.1. Only GCC 5.x (GCC 5.3.0 in Win7, GCC 5.2.1 in Knoppix 7.6) gives the abnormal makefile abort.
The older GCC's are better for making builds for older OS's. They are probably also better for a longterm project like GnuCOBOL that includes older code. (Why use a GCC compiler from 2017 to compile code written in 2007?)
Anon
View and moderate all "Help getting started" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
In the GCC 6.3.0 build, I initially got the same "Permission denied" error that Arnold did. I did not report the error because I thought I had made a typo. I just re-typed the entire ./configure and it ran.
My build did not use the MinGW installer -- instead I followed the MinGW/MSYS Installation Guide.
The error did not occur in any of the builds with earlier GCC's. The config logs from all of the previous builds are attached so that maybe you can determine the cause of the problem.
Anon