Now that I have GC31 and GC32 working on my Windoze systems, I thought I would try it out on my Linux Mint 19.2 system. In another thread, someone (complaining about the difficulty of installing GC in Windoze) said that GC could be installed in Linux as follows:
apt-get install gnucobol
Of course, that simply returns "E: Unable to locate package gnucobol"
So, where is the "repository" I should be searching, or what is the (more complicated) installation procedure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The instructions are and files are on this page: https://sourceforge.net/projects/open-cobol/files/
The linux install (3.1 ?) basicly is download the needed packages in the Requirements section, then do the Install section which is configure, make, make check, make test , make checkall and then install.
Just read and follow the script carefully.
Note: This works, but is 1.1 version: sudo apt-get install open-cobol
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps that page makes sense to you, but it just adds to my confusion. There is a lengthy (and confusing) discussing of what is supposedly needed, an oblique reference to an INSTALL file (without a link to it), and nothing (that I can see) providing meaningful instructions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please see the INSTALL file and the README which are both provided in any tarball, coming back to make specific suggestions to possibly adjust the README.
Note: the way to install pre-requisite packages are not to be part of the README as this differs in many systems - apt, dpkg, pacman, yum, cygwin-setup.exe, ... (thought it should be mentioned that the installation is normally best done with the system's package manager, whatever it is).
Thank you for taking the time to suggest concrete changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What do you mean by can't understand? I assume you've found the files README and INSTALL which are included in every tarball of GnuCOBOL at the directory root, didn't you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It doesn't say the instructions are to be found in the README and INSTALL files, which (in turn) can be found in the tarball --- so how would I even know to look for them, and how would they help me figure out where to find the right tarball?
The linux install (3.1 ?) basicly is download the needed packages in the Requirements section, then do the Install section which is configure, make, make check, make test , make checkall and then install.
Again, perfectly clear if you already know the procedure and location of the files. Very oblique if you don't.
Just read and follow the script carefully.
Which script would that be? One might logically assume that it meant " the instructions ...[found] on this page: https://sourceforge.net/projects/open-cobol/files/, not yet another set of instructions, found elsewhere, if you even know to look for them.
As I said in my earlier comment, **Perhaps that page makes sense to you, but it just adds to my confusion.
Last edit: cdg 2019-12-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Secondly, why isn't pdcurses at all compatible with ncurses? I'm getting the following intrinsic functions flagged as errors with ncurses: initscr, endwin, start_color, init_pair, attron, attroff, printw, refresh, and getch!
Last edit: cdg 2019-12-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I had to change include <curses.h> to include <ncurses.h> and printf("%s %s", "ncurses version is ", NCURSES_VERSION, "\n"); to
`printf("ncurses version is %s\n", NCURSES_VERSION);, but it still doesn't like any of the pdcurses functions.
1) ncurses problem solved: I need to include -lncurses on the gcc or cobc command line.
2) Unfortunately, colortest reveals that ncurses handles colors completely differently than every version of pdcurses. So now we have four different results (pdcurses 3.4, pdcurses 3.9, pdcurses 4.0, and ncurses 6.1) for the same program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-12-22
Looking up "cobol" at pkgs.org shows which distros have some version of COBOL and how to install them:
Maybe this is why none of the distros have GC3.1 in them yet.
The reason is that distros normally only use release tarballs (possibly including RC) and GC3.1 is not there, yet.
Actually your test results are fine - VBISAM (and the other ISAM handlers) do have some features which are not available with the GC3.1 bdb implementation, which is the reason for some unexpected pass. On the other hand there is not-yet a "real" official VBISAM release with all fixes included which is a reason that you get some fails on edge cases (for some people partial keys and sparse keys are important, for others not [the expected official release of VBISAM in 2020 will pass all those tests]). Older GC tarballs just did not test for these options at all (you don't have any new defects in). For reference I'm quoting the summary here:
I'm not sure yet. but the 3.1RC will either have the tests included as they are (likely leading to a bunch of questions here and in the mailing list) or set them to SKIP.
Still: thank you for the report as this should help at least people using the search function of this board to know more of this issue.
Note: if you send (the main) testsuite.log then config.log is included there, no need to additional attach it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, in other words, we can go through an extremely complicated installation process, culled from multiple and contradictory sources, and end up with GC3.1 minus ISAM and pdcurses?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-12-24
@cdg,
If you use BDB as the file handler, you can build gnucobol-3.1-dev in Linux Mint 19.2
in four easy steps:
STEP 1 -- Install 33 .deb packages needed for GC3 (see att.)
STEP 2 -- Install MPIR from source:
cd~/cob# use any directory name
tarxvjfmpir-3.0.0.tar.bz2
cdmpir-3.0.0
./configure--prefix=/usr/local--disable-static--enable-shared--enable-gmpcompat
make
makecheck
sudomakeinstall
STEP 3 -- Install GnuCOBOL from source:
cd~/cob
tarxvzfgnucobol-3.1-dev.tar.gz
cdgnucobol-3.1-dev
exportLD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
./configure--prefix=/usr/local--with-dbCPPFLAGS=-I/usr/local/include[onsamelinewithnextstatement]LDFLAGS=-L/usr/local/lib[-Imeans-eye,not-ell]
make
makecheck
sudomakeinstall
sudoldconfig
Despite the "why installing directly with deb packages" question which was raised (and should be answered) in another thread: why does you list include help2man, yacc, python and a bunch of other stuff? You are very likely having a reason for this but I did not get the point yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How come we have someone posting so many messages as 'Anonymous' - I got somewhat rebuked for doing that a while ago. OR - does someone actually have that username ??.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's "Anon", a person that is seen from time to time and "prefers to keep an air of mystery" with taking into consideration that some mod always needs to unlock these posts.
I still would personally suggest to better use a throw-away mail account, registering with it here and have a "real" account over posting anonymous, but as the general spam level here is low enough we allow anonymous posts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's too early for April Fool's Day. None of the packages you list exist (at least as far as "apt install" is concerned). And the bash commands you list for steps 2 and 3 generate a slew of error messages. Now I see why Ken changed the pkgs.lst. Bad advice is far worse than no advice at all.
Last edit: cdg 2019-12-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anon uses the debian packages (=packages for the concrete architecture with specific version), not the "meta" packages apt normally uses.
If you use apt then the package manager takes care of this, along with ensuring you also have the dependency packages installed, if you use dpkg then you are on the concrete package level. That's no necessarily "bad advice" (I actually find it nice that someone provided the list, even when I do not understand why some of the packages were chosen).
And there actually are reasons to do this, but those aren't "common uses". A quote from the dpkg manpage:
dpkg is a tool to install, build, remove and manage Debian packages. The primary and more user-friendly front-end for dpkg is aptitude.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For those of us who are unfamilliar with the bits and bytes of Linux, the pkgs.lst was less than helpful. I finally guessed that we should obtain those packages via "apt install", but it was only a guess, and it didn't help with the MPIR or GC31 tarballs, which took more guesswork.
Yes, it is very nice that someone provided the list, but why not put in a little more effort and make it a usable list?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I followed your directions. See attached mint-19.2.lst of install files.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
./configure --prefix=/usr/local --with-db CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
Went well
make went well
make check failed. I stopped it after several failures.
General tests of used binaries
1: Compiler help and information ok
2: Compiler outputs (general) FAILED (used_binaries.at:66)
3: Compiler outputs (file specified) FAILED (used_binaries.at:106)
4: Compiler outputs (path specified) FAILED (used_binaries.at:135)
5: Compiler outputs (assembler) FAILED (used_binaries.at:167)
6: Source file not found ok
7: Temporary path invalid FAILED (used_binaries.at:204)
8: Using full path for cobc FAILED (used_binaries.at:235)
9: C Compiler optimizations FAILED (used_binaries.at:253)
10: Invalid cobc option ok
11: cobcrun help and information ok
Your list: gcc-6-base -y
sudo apt install gcc-8-base -y
You have apparently used the Debion 10.2 file list, rather than the Linux Mint list; and you have removed the version and application qualifiers, which (assuming it works at all) implies you may be getting a different library version? And, by specifying "-y", you might miss an important error or warning message.
I don't know why "anon" couldn't have provided a usable install script, instead of a confusing table to go with an already overly-complicated procedure. And why should ANY program require the installation of 33 other program libraries?
"I could have done it in a much more complicated way," said the Red Queen, immensely proud.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it does not make sense to go on with the tests if those tests already fail. But the provided list does not allow any reasonable suggestions, testuite.log would.
You may limit the amount of tests by specifying a subset to test: make check TESTSUITEFLAGS="-k cobc,cobcrun".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I have GC31 and GC32 working on my Windoze systems, I thought I would try it out on my Linux Mint 19.2 system. In another thread, someone (complaining about the difficulty of installing GC in Windoze) said that GC could be installed in Linux as follows:
Of course, that simply returns "E: Unable to locate package gnucobol"
So, where is the "repository" I should be searching, or what is the (more complicated) installation procedure.
The instructions are and files are on this page: https://sourceforge.net/projects/open-cobol/files/
The linux install (3.1 ?) basicly is download the needed packages in the Requirements section, then do the Install section which is configure, make, make check, make test , make checkall and then install.
Just read and follow the script carefully.
Note: This works, but is 1.1 version: sudo apt-get install open-cobol
Perhaps that page makes sense to you, but it just adds to my confusion. There is a lengthy (and confusing) discussing of what is supposedly needed, an oblique reference to an INSTALL file (without a link to it), and nothing (that I can see) providing meaningful instructions.
Please see the INSTALL file and the README which are both provided in any tarball, coming back to make specific suggestions to possibly adjust the README.
Note: the way to install pre-requisite packages are not to be part of the README as this differs in many systems - apt, dpkg, pacman, yum, cygwin-setup.exe, ... (thought it should be mentioned that the installation is normally best done with the system's package manager, whatever it is).
Thank you for taking the time to suggest concrete changes.
We can't suggest concrete changes if we can't understand what is currently there. :-(
What do you mean by can't understand? I assume you've found the files README and INSTALL which are included in every tarball of GnuCOBOL at the directory root, didn't you?
You assume incorrectly.
It doesn't say the instructions are to be found in the README and INSTALL files, which (in turn) can be found in the tarball --- so how would I even know to look for them, and how would they help me figure out where to find the right tarball?
Again, perfectly clear if you already know the procedure and location of the files. Very oblique if you don't.
Which script would that be? One might logically assume that it meant " the instructions ...[found] on this page: https://sourceforge.net/projects/open-cobol/files/, not yet another set of instructions, found elsewhere, if you even know to look for them.
As I said in my earlier comment, **Perhaps that page makes sense to you, but it just adds to my confusion.
Last edit: cdg 2019-12-25
Secondly, why isn't pdcurses at all compatible with ncurses? I'm getting the following intrinsic functions flagged as errors with ncurses: initscr, endwin, start_color, init_pair, attron, attroff, printw, refresh, and getch!
Last edit: cdg 2019-12-22
OK, I had to change
include <curses.h>toinclude <ncurses.h>andprintf("%s %s", "ncurses version is ", NCURSES_VERSION, "\n");to`printf("ncurses version is %s\n", NCURSES_VERSION);, but it still doesn't like any of the pdcurses functions.
Last edit: cdg 2019-12-22
12/25/2019
1) ncurses problem solved: I need to include
-lncurseson thegccorcobccommand line.2) Unfortunately, colortest reveals that ncurses handles colors completely differently than every version of pdcurses. So now we have four different results (pdcurses 3.4, pdcurses 3.9, pdcurses 4.0, and ncurses 6.1) for the same program.
Looking up "cobol" at pkgs.org shows which distros have some version of COBOL and how to install them:
ALT Linux Sisyphus (gnucobol-2.2): https://altlinux.pkgs.org/sisyphus/classic-x86_64/gnucobol-2.2-alt1.x86_64.rpm.html
CentOS (open-cobol-1.1): https://centos.pkgs.org/7/psychotic-ninja-x86_64/open-cobol-1.1-5.el7.psychotic.x86_64.rpm.html
Debian (gnucobol_2.2): https://debian.pkgs.org/10/debian-main-amd64/gnucobol_2.2-5_amd64.deb.html
*Fedora (gnucobol-3.0rc1): https://fedora.pkgs.org/31/rpm-sphere-x86_64/gnucobol-3.0rc1-16.1.x86_64.rpm.html
FreeBSD (gnu-cobol-2.2):
https://freebsd.pkgs.org/12/freebsd-ports-latest-amd64/gnu-cobol-2.2_1.txz.html
*NetBSD (gnucobol-2.2):
https://netbsd.pkgs.org/8.1/netbsd-amd64/gnucobol-2.2.tgz.html
openSUSE (gnu-cobol-3.0rc1):
https://opensuse.pkgs.org/tumbleweed/opensuse-oss/gnu-cobol-3.0rc1-2.3.x86_64.rpm.html
Slackware (gnucobol-2.2):
https://slackware.pkgs.org/current/slackware-x86_64/gnucobol-2.2-x86_64-2.txz.html
Ubuntu (gnucobol_2.2):
https://ubuntu.pkgs.org/19.10/ubuntu-universe-amd64/gnucobol_2.2-5_amd64.deb.html
I put a "*" next to the most COBOL-friendly distros:
-Fedora also has a Japanese-friendly UTF-8 version, open-cobol-1.1, and tinycobol-0.66
-NetBSD also has a Japanese-friendly UTF-8 version, open-cobol-1.1, open-cobol-ce, and an EMACS mode for editing
There are no COBOL packages listed for Linux Mint (an error?)
--Anon
The first question was in respect to GC3.1 and GC3.2 and Mint
The second question was in respect to ncurses 6.1
Last edit: cdg 2019-12-23
@cdg,
I tried to build GC31-dev in Linux Mint 19.2 (MATE, 64-bit) using the procedure on pp. 2-4 of
the Install Guide v6 with only these changes:
-use mpir-3.0.0.tar.bz2 and gnucobol-3.1-dev.tar.gz
-install prerequisites help2man_1.47.6_amd64.deb,
libncurses5-dev_6.1-1ubuntu1.18.04_amd64.deb,
libtinfo-dev_6.1-1ubuntu1.18.04_amd64.deb,
yasm_1.3.0-2build1_amd64.deb
-skip help2man and ncurses builds (they are already installed in the prerequisites above)
Unfortunately, the build fails during the 'make check' of GC3.1. (See report att.)
Maybe this is why none of the distros have GC3.1 in them yet.
--Anon
The reason is that distros normally only use release tarballs (possibly including RC) and GC3.1 is not there, yet.
Actually your test results are fine - VBISAM (and the other ISAM handlers) do have some features which are not available with the GC3.1 bdb implementation, which is the reason for some unexpected pass. On the other hand there is not-yet a "real" official VBISAM release with all fixes included which is a reason that you get some fails on edge cases (for some people partial keys and sparse keys are important, for others not [the expected official release of VBISAM in 2020 will pass all those tests]). Older GC tarballs just did not test for these options at all (you don't have any new defects in). For reference I'm quoting the summary here:
I'm not sure yet. but the 3.1RC will either have the tests included as they are (likely leading to a bunch of questions here and in the mailing list) or set them to
SKIP.Still: thank you for the report as this should help at least people using the search function of this board to know more of this issue.
Note: if you send (the main) testsuite.log then config.log is included there, no need to additional attach it.
So, in other words, we can go through an extremely complicated installation process, culled from multiple and contradictory sources, and end up with GC3.1 minus ISAM and pdcurses?
@cdg,
If you use BDB as the file handler, you can build gnucobol-3.1-dev in Linux Mint 19.2
in four easy steps:
STEP 1 -- Install 33 .deb packages needed for GC3 (see att.)
STEP 2 -- Install MPIR from source:
STEP 3 -- Install GnuCOBOL from source:
STEP 4 -- Test GnuCOBOL:
The end of the 'make check' reports
so you get almost all of the features of GnuCOBOL. (The nodejs-dev package
would not install in Linux Mint 19.2.)
Hope this helps.
--Anon
Last edit: Simon Sobisch 2019-12-24
Despite the "why installing directly with deb packages" question which was raised (and should be answered) in another thread: why does you list include help2man, yacc, python and a bunch of other stuff? You are very likely having a reason for this but I did not get the point yet.
How come we have someone posting so many messages as 'Anonymous' - I got somewhat rebuked for doing that a while ago. OR - does someone actually have that username ??.
That's "Anon", a person that is seen from time to time and "prefers to keep an air of mystery" with taking into consideration that some mod always needs to unlock these posts.
I still would personally suggest to better use a throw-away mail account, registering with it here and have a "real" account over posting anonymous, but as the general spam level here is low enough we allow anonymous posts.
@Anon,
It's too early for April Fool's Day. None of the packages you list exist (at least as far as "apt install" is concerned). And the bash commands you list for steps 2 and 3 generate a slew of error messages. Now I see why Ken changed the pkgs.lst. Bad advice is far worse than no advice at all.
Last edit: cdg 2019-12-25
Anon uses the debian packages (=packages for the concrete architecture with specific version), not the "meta" packages
aptnormally uses.If you use
aptthen the package manager takes care of this, along with ensuring you also have the dependency packages installed, if you usedpkgthen you are on the concrete package level. That's no necessarily "bad advice" (I actually find it nice that someone provided the list, even when I do not understand why some of the packages were chosen).And there actually are reasons to do this, but those aren't "common uses". A quote from the dpkg manpage:
For those of us who are unfamilliar with the bits and bytes of Linux, the pkgs.lst was less than helpful. I finally guessed that we should obtain those packages via "apt install", but it was only a guess, and it didn't help with the MPIR or GC31 tarballs, which took more guesswork.
Yes, it is very nice that someone provided the list, but why not put in a little more effort and make it a usable list?
I followed your directions. See attached mint-19.2.lst of install files.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
./configure --prefix=/usr/local --with-db CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
Went well
make went well
make check failed. I stopped it after several failures.
General tests of used binaries
1: Compiler help and information ok
2: Compiler outputs (general) FAILED (used_binaries.at:66)
3: Compiler outputs (file specified) FAILED (used_binaries.at:106)
4: Compiler outputs (path specified) FAILED (used_binaries.at:135)
5: Compiler outputs (assembler) FAILED (used_binaries.at:167)
6: Source file not found ok
7: Temporary path invalid FAILED (used_binaries.at:204)
8: Using full path for cobc FAILED (used_binaries.at:235)
9: C Compiler optimizations FAILED (used_binaries.at:253)
10: Invalid cobc option ok
11: cobcrun help and information ok
Ken
Ken,
Why does your "mint-19.2.lst" not match the pkgs.lst in the directions that you say you followed?
For example:
Directions: gcc-6-base_6.4.0-17ubuntu1_amd64.deb
gir1.2-harfbuzz-0.0_1.7.2-1ubuntu1_amd64.deb
Your list: gcc-6-base -y
sudo apt install gcc-8-base -y
You have apparently used the Debion 10.2 file list, rather than the Linux Mint list; and you have removed the version and application qualifiers, which (assuming it works at all) implies you may be getting a different library version? And, by specifying "-y", you might miss an important error or warning message.
I don't know why "anon" couldn't have provided a usable install script, instead of a confusing table to go with an already overly-complicated procedure. And why should ANY program require the installation of 33 other program libraries?
"I could have done it in a much more complicated way," said the Red Queen, immensely proud.
Yes, it does not make sense to go on with the tests if those tests already fail. But the provided list does not allow any reasonable suggestions, testuite.log would.
You may limit the amount of tests by specifying a subset to test:
make check TESTSUITEFLAGS="-k cobc,cobcrun".