Yesterday the compiles of my program generated no errors. This morning my computer halted due to a power fail. Since then any attempt to compile my program gives the following errors (no changes have been made to the environment or source file):
[/CobolSQLite3-Dev]$ cobc -o CobolSQLite3.so -debug CobolSQLite3.cob -lsqlite3
In file included from /tmp/cob3583_0.c:2012:0:
/tmp/cob3583_0.c.l6.h: In function ‘DBBIND_’:
/tmp/cob3583_0.c.l6.h:20:1: error: unknown type name ‘cob_decimal’
cob_decimal *d0 = NULL;
^
/tmp/cob3583_0.c:2104:3: warning: implicit declaration of function ‘cob_decimal_set_field’ [-Wimplicit-function-declaration]
cob_decimal_set_field (d0, cob_intr_numval (cob_intr_trim (0, 0, COB_SET_DATA
^
/tmp/cob3583_0.c:2105:3: warning: implicit declaration of function ‘cob_decimal_get_field’ [-Wimplicit-function-declaration]
cob_decimal_get_field (d0, &f_97, 0);
^ [/CobolSQLite3-Dev]$
I ask that somebody who has downloaded CobolSQLite3 A.01.00 please let me know if they get the same results as above.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lookes like the gmp/mpir header is there, but broken. Explanation: the included libcob header is used both for generated modules (which expect the header to be included first) and for the C-API (which don't care). The cob_decimal parts (needed for modules) are only defined with the necessary GMP parts defined.
Short: check your gmp/mpir header.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reinstalled GMP (6.2.1) but it made no difference. Then reinstalled GnuCOBOL (3.1.2) but it also made no difference.
I commented out the routine and recompiled getting no errors. Uncommented the routine and did some experimenting.
Found that replacing compute param-idx-wrk = numval(trim(param-idx)) end-compute with move numval(trim(param-idx)) to param-idx-wrk corrected the problem. Not sure why.
'param-idx' is a 'pic x any length' in linkage and 'param-idx-wrk' is a 'pic 9(2)' in working-storage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's something I can explain, partially because of looking at the decimal handling in GnuCOBOL to find a long-standing bug...
A MOVE statement (I'll leave non-numeric handling and editing/de-editingand EC-DATA-CONVERSION and EC-DATA-OVERFLOW[floating-point] exception conditions which are not relevant to this specific case out of the inspection) always assigns the result (in this case - function - a cob_field) to the target, with possible truncation () depending on the field length.
A COMPUTE statement uses an internal high-precision decimal (where we use the appropriate GMP storage as part of our cob_decimal) with multiple clauses that possibly post (or even mid-)change the decimal, including ibm-truncation, iso-rounding, and sets the EC-DATA-OVERFLOW exception condition...
The EC-DATA-OVERFLOW exception condition is the only reason that - even in this special case - the result is not identical.
Hm, can you write-up a minimal example of the program with COMPUTE that fails to compile? Just to allow others to recheck....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
$ cobc --version
cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://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 Feb 15 2021 12:16:13
Packaged Dec 23 2020 12:04:58 UTC
C version "5.4.0 20160609"
$
"Good" news: I can't reproduce that with 2.2, but can with 3.1.2 - will be fixed in 3.2.
As a workaround you can add -A --include=gmp.h to your cobc command.
Would you mind to create a bug report via the tracker?
Last edit: Simon Sobisch 2021-02-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yesterday the compiles of my program generated no errors. This morning my computer halted due to a power fail. Since then any attempt to compile my program gives the following errors (no changes have been made to the environment or source file):
[/CobolSQLite3-Dev]$ cobc -o CobolSQLite3.so -debug CobolSQLite3.cob -lsqlite3
In file included from /tmp/cob3583_0.c:2012:0:
/tmp/cob3583_0.c.l6.h: In function ‘DBBIND_’:
/tmp/cob3583_0.c.l6.h:20:1: error: unknown type name ‘cob_decimal’
cob_decimal *d0 = NULL;
^
/tmp/cob3583_0.c:2104:3: warning: implicit declaration of function ‘cob_decimal_set_field’ [-Wimplicit-function-declaration]
cob_decimal_set_field (d0, cob_intr_numval (cob_intr_trim (0, 0, COB_SET_DATA
^
/tmp/cob3583_0.c:2105:3: warning: implicit declaration of function ‘cob_decimal_get_field’ [-Wimplicit-function-declaration]
cob_decimal_get_field (d0, &f_97, 0);
^
[/CobolSQLite3-Dev]$
I ask that somebody who has downloaded CobolSQLite3 A.01.00 please let me know if they get the same results as above.
Lookes like the gmp/mpir header is there, but broken. Explanation: the included libcob header is used both for generated modules (which expect the header to be included first) and for the C-API (which don't care). The cob_decimal parts (needed for modules) are only defined with the necessary GMP parts defined.
Short: check your gmp/mpir header.
@Simon,
Reinstalled GMP (6.2.1) but it made no difference. Then reinstalled GnuCOBOL (3.1.2) but it also made no difference.
I commented out the routine and recompiled getting no errors. Uncommented the routine and did some experimenting.
Found that replacing compute param-idx-wrk = numval(trim(param-idx)) end-compute with move numval(trim(param-idx)) to param-idx-wrk corrected the problem. Not sure why.
'param-idx' is a 'pic x any length' in linkage and 'param-idx-wrk' is a 'pic 9(2)' in working-storage.
That's something I can explain, partially because of looking at the decimal handling in GnuCOBOL to find a long-standing bug...
A
MOVEstatement (I'll leave non-numeric handling and editing/de-editingandEC-DATA-CONVERSIONandEC-DATA-OVERFLOW[floating-point] exception conditions which are not relevant to this specific case out of the inspection) always assigns the result (in this case - function - a cob_field) to the target, with possible truncation () depending on the field length.A
COMPUTEstatement uses an internal high-precision decimal (where we use the appropriate GMP storage as part of our cob_decimal) with multiple clauses that possibly post (or even mid-)change the decimal, including ibm-truncation, iso-rounding, and sets theEC-DATA-OVERFLOWexception condition...The
EC-DATA-OVERFLOWexception condition is the only reason that - even in this special case - the result is not identical.Hm, can you write-up a minimal example of the program with
COMPUTEthat fails to compile? Just to allow others to recheck....@Simon
As requested.
$ cobc --version
cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://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 Feb 15 2021 12:16:13
Packaged Dec 23 2020 12:04:58 UTC
C version "5.4.0 20160609"
$
"Good" news: I can't reproduce that with 2.2, but can with 3.1.2 - will be fixed in 3.2.
As a workaround you can add
-A --include=gmp.hto your cobc command.Would you mind to create a bug report via the tracker?
Last edit: Simon Sobisch 2021-02-17