admittedly it's a comparison of a mingw build of 3.2 with a whatever yours is:
but the difference (major that is ) starts about here:
see attached comparison of my build log with yours.
Don't know if it helps. - haven't kept a log of a 3.1 build for yonks.
The issue seems that mpz_abs as used in numeric.c and intrinsic.c (defined as __gmpz_abs) and is integrated into the object file, similar with the "fits" functions in common.c and intrinsic.c.
The most reasonable guess is that they already get in with including the header.
Mabe config.log helps a bit - if you know which header is used then please attach it, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's no real issue - configure actually tests a bunch of things and then checks with the correct compilation if the tested feature works or not; as long as configure does not error the make step should pass, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As this is all GMP related and GMP is quite old which has a lot of effect on arithmetic performance I'd suggest to:
download, configure and install GMP - possibly with an explicit --prefix to not affect other parts of the system
export LD_LIBRARY_PATH accordingly (add the installed library directory), then run GnuCOBOL's configure with PKG_CONFIG_PATH=/path/to/gmps/pc (or as an alternative the complete CPPFLAGS and LDFLAGS necessary)
This should result in an output of "GMP 6.2.1" instead of "GMP 4.2" - and hopefully a working make.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ping @kitamanswinner - any update with your 32bit GMP build for your 32bit GnuCOBOL environment?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-01-21
I downloaded the current version of gmp621.
Configure ran ok, and compiled ok,
When it came to linking, there was a problem with about a dozen programs (assert.o among others) that were pre-compiled in the distribution using Ubuntu gcc, and when I tried to individually compile those, the compilation failed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then either some system libraries are only 64 bit or the linker path point to those or... my configure line was not as good as it should have been: CFLAGS="-m32" LDFLAGS="-m32" (and potentially include / library paths to point to 32bit first).
Last edit: Simon Sobisch 2022-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using:
./configure CFLAGS="-m32" LDFLAGS="-m32"
I get the following error:
....
checking size of unsigned long... 4
checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.
unix:/tmp/gmp621.4#
Some days I wish I had learned to compile C programs, other days I am glad I didn't.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately SCO is 32bit only.
Ran with additional ABI=32 on configure, then had to make a .libs directory and copy all existing .o files to it.
Then ended with the same problem:
.libs/assert.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make[2]: [libgmp.la] Error 1
make[2]: Leaving directory /tmp/gmp621.4'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory/tmp/gmp621.4'
make: [all] Error 2
unix:/tmp/gmp621.4#
make does not create the .libs directory.
When I created it myself, and copied the existing .o files to it, they were not changed by make.
When I deleted the .o files in .libs, and also deleted the .o files in the distribution, the associated .c files were not compiled.
The only issue that is noted in GMPs Known Build Problems is that you rather should use GNU make than the system one.
For one ABI=32 it is listed that there are build issues when you don't add --disable-shared.
Please report your findings:
configure chooses to build 64bit ABI (but that seems to be related to gcc defaulting to 64bit, which is quite strange for a 32bit only OS; so maybe GCC is to blame?)
linking does not work because the distribution-shipped assert.o fails to link
Linux users generally start a script with #!/bin/sh assuming that it is a link to /bin/bash. This is not true with SCO, as for backwards compatibility, the original Bourne shell sh is shipped along with ksh93 and bash. Once I changed /bin/sh to be /bin/bash, I was able to install gmp-6.2.1, after which I added /usr/local/lib to LD_LIBRARY_PATH and did configure, make and make test for gnucobol.
I edited the testsuite.log and just attached the errors, most of which were expected.
@Simon, can you send me a private email, I lost your email address last October when I ran out of disk space and tried unsuccessfully to re-partition the disk (don't ask).
Last edit: Jack Tearle 2022-02-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to know that the shell was the reason for the build issues, I guess there would have been the option to manually start bash and pass SHELL=/bin/bash to configure (that won't help for scripts, of course).
You can commonly upload testsuite.log here (potentially after removing the minor pieces that would show the system environment); which would be useful for you to receive general answers also from others and will also others show both the potential issue and the solution together.
If you really need personal support then we possibly could find an agreement (and there are companies doing this, too); if there's no bigger thing like in this case you find my email address in at least every ChangeLog file in the gnucobol folder.
That said: can you please check the results with the GnuCOBOL nightly instead of the old 31rc-1?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed gnucobol-4.0-early-dev. Attached is the testsuite.log
I had to cancel tests 850,851,1109 and 1110, as they appeared to be hung (ran for minutes).
Any help with this error, compiler is gcc version 7.3.0
Are you using one of the Windows build from the Arnold website ?
If not, I suggest you do so.
No, it is the gnucobol-3.1.2 that I downloaded today.
Environment is gcc 7.3.0 on SCO Unix.
admittedly it's a comparison of a mingw build of 3.2 with a whatever yours is:
but the difference (major that is ) starts about here:
see attached comparison of my build log with yours.
Don't know if it helps. - haven't kept a log of a 3.1 build for yonks.
Please provide config.log, too.
The issue seems that
mpz_absas used in numeric.c and intrinsic.c (defined as__gmpz_abs) and is integrated into the object file, similar with the "fits" functions in common.c and intrinsic.c.The most reasonable guess is that they already get in with including the header.
Mabe config.log helps a bit - if you know which header is used then please attach it, too.
I made a change to LD_LIBRARY_PATH and ran configure and make again.
Something wrong with the configure - every ten lines or so it's 'compilation terminated'.
No wonder the make fails.
That's no real issue - configure actually tests a bunch of things and then checks with the correct compilation if the tested feature works or not; as long as configure does not error the make step should pass, too.
As this is all GMP related and GMP is quite old which has a lot of effect on arithmetic performance I'd suggest to:
--prefixto not affect other parts of the systemLD_LIBRARY_PATHaccordingly (add the installed library directory), then run GnuCOBOL'sconfigurewithPKG_CONFIG_PATH=/path/to/gmps/pc(or as an alternative the completeCPPFLAGSandLDFLAGSnecessary)This should result in an output of "GMP 6.2.1" instead of "GMP 4.2" - and hopefully a working
make.More troubles, does GMP 6.2.1 now require a 64bit system?
No, it doesn't. Try to run
configure CC="gcc -m32"and see if this is better (assuming you actually want a 32bit GnuCOBOL).Ping @kitamanswinner - any update with your 32bit GMP build for your 32bit GnuCOBOL environment?
I downloaded the current version of gmp621.
Configure ran ok, and compiled ok,
When it came to linking, there was a problem with about a dozen programs (assert.o among others) that were pre-compiled in the distribution using Ubuntu gcc, and when I tried to individually compile those, the compilation failed.
Then either some system libraries are only 64 bit or the linker path point to those or... my configure line was not as good as it should have been:
CFLAGS="-m32" LDFLAGS="-m32"(and potentially include / library paths to point to 32bit first).Last edit: Simon Sobisch 2022-01-21
Using:
./configure CFLAGS="-m32" LDFLAGS="-m32"
I get the following error:
....
checking size of unsigned long... 4
checking size of mp_limb_t... 4
configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
in this configuration expects 64 bits.
You appear to have set $CFLAGS, perhaps you also need to tell GMP the
intended ABI, see "ABI and ISA" in the manual.
unix:/tmp/gmp621.4#
Some days I wish I had learned to compile C programs, other days I am glad I didn't.
The GMP manual says: add ABI=32 (and mentions that a 64bit build would be faster).
Unfortunately SCO is 32bit only.
Ran with additional ABI=32 on configure, then had to make a .libs directory and copy all existing .o files to it.
Then ended with the same problem:
.libs/assert.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make[2]: [libgmp.la] Error 1
make[2]: Leaving directory
/tmp/gmp621.4' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/tmp/gmp621.4'make: [all] Error 2
unix:/tmp/gmp621.4#
partial content of assert.o :
%d:
GNU MP assertion failed: %s
GCC: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
assert.c
.LC0
.LC1
.LC2
__gmp_assert_header
stderr
GLOBAL_OFFSET_TABLE
__fprintf_chk
I don't know how to get past this, as assert.o is part of the distribution.
What do you mean with
?
When you run make it should create this directory and compile the files into it.
make does not create the .libs directory.
When I created it myself, and copied the existing .o files to it, they were not changed by make.
When I deleted the .o files in .libs, and also deleted the .o files in the distribution, the associated .c files were not compiled.
The only issue that is noted in GMPs Known Build Problems is that you rather should use GNU make than the system one.
For one
ABI=32it is listed that there are build issues when you don't add--disable-shared.Please report your findings:
to the GMP Bugs mailing list.
Finally. I have attached the errors from 'make check' .
What files are necessary to create a downloadable binary package?
What did you do to now have a working compile?
For the testsuite: there is tests/testsuite.log, please attach that to inspect the failures.
Can you please do a second build (possibly in a folder next to yours) using a 3.2 nightly build? You can find the URLs at https://sourceforge.net/projects/gnucobol/files/gnucobol/nightly_snapshots/ - I guess the results are possibly better.
Linux users generally start a script with #!/bin/sh assuming that it is a link to /bin/bash. This is not true with SCO, as for backwards compatibility, the original Bourne shell sh is shipped along with ksh93 and bash. Once I changed /bin/sh to be /bin/bash, I was able to install gmp-6.2.1, after which I added /usr/local/lib to LD_LIBRARY_PATH and did configure, make and make test for gnucobol.
I edited the testsuite.log and just attached the errors, most of which were expected.
@Simon, can you send me a private email, I lost your email address last October when I ran out of disk space and tried unsuccessfully to re-partition the disk (don't ask).
Last edit: Jack Tearle 2022-02-05
Good to know that the shell was the reason for the build issues, I guess there would have been the option to manually start bash and pass
SHELL=/bin/bashto configure (that won't help for scripts, of course).You can commonly upload testsuite.log here (potentially after removing the minor pieces that would show the system environment); which would be useful for you to receive general answers also from others and will also others show both the potential issue and the solution together.
If you really need personal support then we possibly could find an agreement (and there are companies doing this, too); if there's no bigger thing like in this case you find my email address in at least every ChangeLog file in the gnucobol folder.
That said: can you please check the results with the GnuCOBOL nightly instead of the old 31rc-1?
I installed gnucobol-4.0-early-dev. Attached is the testsuite.log
I had to cancel tests 850,851,1109 and 1110, as they appeared to be hung (ran for minutes).