Menu
▾
▴
tiny-cobol-users
|
From: vince c. <vb...@bt...> - 2006-12-28 17:05:52
|
Hi all;
I Have now installed tc .63 but getting a lot of errors.
Can't run the test_suite without a lot of errors. Ditto when compiling hello
world. Can someone help?
I have in my ,bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
export TCOB_DIR=3D/home/vince
export TCOB_PPDIR=3D/usr/local/share/htcobol
export TCOB_OPTIONS_PATH=3D/usr/local/share/htcobol
export TCOB_LD_LIBRARY_PATH=3D/home/vince/cobolsrc/libs
CCX=3Dgcc; export CCX
LD=3Dgcc; export LD
ASM=3Das; export ASM
There is nothing in cobolsrc/libs
In htcobolrc :
COPYBOOK_PATH: /usr/local/share/htcobol/copybooks;.;
PGM_SUFFIXES: .cob:.COB:.cbl:.CBL:
PGM_FORMAT_FREE
PGM_ENTRY_POINT_AUTO
COMPILE_DEFAULT: PCAL
NODEBUG_LINES
NOLIST
PGMLIST_SUFFIX: .lst
XREF
ASX_CMD: as
CCX_CMD: gcc
ARX_CMD: ar
RANLIBX_CMD: ranlib
SHLIB_NAME_DEFAULT: lib$.so
LD_PATH: -L/usr/local/lib -L/usr/lib -L/opt/cobol/lib
#LD_PATH:
#LD_PATH: -L/home/vince/temp/lib
LD_HT1_LIBS: -lhtcobol
LD_MATH_LIBS: -lm
LD_READLINE_LIBS: -lreadline
LD_EXTRA_LIBS: -ldl
LD_DCALL_LIBS: -ldl
LD_TERM_LIBS: -lncurses
LD_IO_LIBS: -ldb-4
#
LD_FLAGS:
When running htcobol it produces:
[vince@study development]$ ls -la hello*
=2Drwxr-xr-x 1 vince vince 8136 Dec 28 16:32 hello*
=2Drw-r--r-- 1 vince vince 98 Dec 28 00:37 hello.cbl
=2Drw-r--r-- 1 vince vince 1470 Dec 28 15:46 hello.lst
When running ./hello
It gives me:
=2E/hello: error while loading shared libraries: libhtcobol.so.0: cannot op=
en
shared object file: No such file or directory
I need to solve this first before attempting the test suite again as most of
the test produce similar to this:
########################################################################
# Validate Alph to Alphanumeric moves #
# Test Directory: format_tests Test File test01 #
########################################################################
Program test01 returned an unexpected return code
Validate Alph to Alphanumeric moves : FAIL=
ED
########################################################################
# Validate Alpha to Formatted Alphanumeric (space) moves #
# Test Directory: format_tests Test File test01a #
########################################################################
Program test01a returned an unexpected return code
Validate Alpha to Formatted Alphanumeric (space) moves : FAIL=
ED
########################################################################
# Validate Alpha to Formatted Alphanumeric (slash) moves #
# Test Directory: format_tests Test File test01b #
########################################################################
Program test01b returned an unexpected return code
The log looks like this (when running make > test.log 2> test.err:
perl cobol_test.pl
Cobol test suite version v010712
Checking to see if your kit is complete
Your kit looks complete.
+++++++++++++++++++++++++
#######################################################
# Testing compiler: #
# .version "01.01" #
#######################################################
Compiling program ctest01 ... Compile return code =3D 16
Compiling program ctest01a ... Compile return code =3D 12
Compiling program ctest01b ... Compile return code =3D 12
Compiling program ctest01c ... Compile return code =3D 0
Compiling program ctest01d ... Compile return code =3D 12
Compiling program ctest01e ... Compile return code =3D 0
Compiling program ctest02 ... Compile return code =3D 16
Compiling program ctestws01 ... Compile return code =3D 0
Compiling program ctestws02 ... Compile return code =3D 0
and the error log like this:
foo_c.c: In function =E2=80=98main=E2=80=99:
foo_c.c:4: warning: incompatible implicit declaration of built-in
function =E2=80=98prin
tf=E2=80=99
Program ctest01 failed to properly compile
Program ctest01a failed to properly compile
Program ctest01b failed to properly compile
Program ctest01d failed to properly compile
Program ctest02 failed to properly compile
Program ctestws03 failed to properly compile
Program ctest04 failed to properly compile
Program ctest05 failed to properly compile
Program ctestsl02 failed to properly compile
Program ctestsl04 failed to properly compile
Program ctestsl06 failed to properly compile
Program ctestsl08 failed to properly compile
Program ctestp-initialize1 failed to properly compile
=2E/test01: error while loading shared libraries: libhtcobol.so.0: cannot o=
pen
sha
red object file: No such file or directory
Program test01 returned an unexpected return code
gcc -v produces:
[vince@study Desktop]$ gcc -v
Using built-in specs.
Target: i586-mandriva-linux-gnu
Configured=20
with: ../configure --prefix=3D/usr --libexecdir=3D/usr/lib --with-slibdir=
=3D/lib --mandir=3D/usr/share/man=20
=2D-infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --en=
able-checking=3Drelease=20
=2D-enable-languages=3Dc,c++,ada,fortran,objc,obj-c++,java --host=3Di586-ma=
ndriva-linux-gnu --with-cpu=3Dgeneric=20
=2D-with-system-zlib --enable-long-long --enable-__cxa_atexit --enable-cloc=
ale=3Dgnu --disable-libunwind-exceptions=20
=2D-enable-java-awt=3Dgtk --with-java-home=3D/usr/lib/jvm/java-1.4.2-gcj-1.=
4.2.0/jre --enable-gtk-cairo --enable-ssp=20
=2D-disable-libssp
Thread model: posix
gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)
Any Ideas?
Thanks for any help,
Vince.
=2D------------------------------------------------------
|
|
From: David E. <de...@us...> - 2006-12-29 07:38:43
|
Vince Coen wrote: > I Have now installed tc .63 but getting a lot of errors. > Can't run the test_suite without a lot of errors. > Ditto when compiling hello world. > Can someone help? > ... > When running ./hello > > It gives me: > > ./hello: error while loading shared libraries: > libhtcobol.so.0: cannot open > shared object file: No such file or directory This seams to be a very common problem for some reason. The linker needs to locate the RT shared library 'libhtcobol.so.0'. The TC configure will install to a prefix='/usr/local' by default, so the shared library 'libhtcobol.so.0' should be located in the 'usr/local/lib' directory. Unfortunatly, some of the distributions do not use the 'usr/local ...' directories, thus the linker is not set up to search that path. So you can you can do either of the following: 1) Set the 'LD_LIBRARY_PATH' enviroment variable (bash: export LD_LIBRARY_PATH=usr/local/lib), which is a temporary solution. 2) Use the 'ldconf' command to add the path to the linker search path. 3) Configure TC using the `--prefix=/usr' option, then compile and install it. > I need to solve this first before attempting the > test suite again as most of > the test produce similar to this: > ... The test suite on version 0.63 is set up to expect to find the compiler, RTL and resouce files in the source code sub-directories above the 'test_suite' directory (i.e. ../compiler, ../lib, etc.). So it is best to just configure and compiler TC, then run the test suite. Otherwise, modifications to the perl script are required. Hint: Before you run the test suite, remove the RT shared library (and links) or compile the RTL a static library only. Hope this helps. |
|
From: vince c. <vb...@bt...> - 2006-12-29 15:36:58
|
Hi; Now with LD_LIBRARY_PATH set I have run the test_suite make file and programs. The Only failures I get are with srt03, srt05, perf06 but both srtio03/05 compile and execute showing the following respectively: [vince@study sortio_tests]$ export LD_LIBRARY_PATH=/usr/local/lib [vince@study sortio_tests]$ ./srtio03 001,10 00,A0 DD;,A8 DD;,A8 DDV,A8 D 0,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA8,A8 AA0,A8 A03,A8 5D;,A8 04;,A8 SRTIO03:( 0001):( 0020):Record no 0001 SRTIO03:(-3800):( 0010):Record no 0002 SRTIO03:( 2220):( 0019):Record no 0003 SRTIO03:( 2220):( 0009):Record no 0004 SRTIO03:( 2162):( 0018):Record no 0005 SRTIO03:( 1620):( 0008):Record no 0006 SRTIO03:( 1887):( 0017):Record no 0007 SRTIO03:( 1887):( 0007):Record no 0008 SRTIO03:( 1887):( 0016):Record no 0009 SRTIO03:( 1887):( 0006):Record no 0010 SRTIO03:( 1887):( 0015):Record no 0011 SRTIO03:( 1887):( 0005):Record no 0012 SRTIO03:( 1887):( 0014):Record no 0013 SRTIO03:( 1887):( 0013):Record no 0014 SRTIO03:( 1887):( 0004):Record no 0015 SRTIO03:( 1887):( 0003):Record no 0016 SRTIO03:( 1870):( 0012):Record no 0017 SRTIO03:( 1703):( 0002):Record no 0018 SRTIO03:( 0720):( 0011):Record no 0019 SRTIO03:( 0060):( 0001):Record no 0020 [vince@study sortio_tests]$ and for srtio05 [vince@study sortio_tests]$ ./srtio05 SRTIO05:( 0001):( 0020):Record no 0001 SRTIO05:(-3800):( 0010):Record no 0002 SRTIO05:( 2220):( 0019):Record no 0003 SRTIO05:( 2220):( 0009):Record no 0004 SRTIO05:( 2162):( 0018):Record no 0005 SRTIO05:( 1620):( 0008):Record no 0006 SRTIO05:( 1887):( 0017):Record no 0007 SRTIO05:( 1887):( 0007):Record no 0008 SRTIO05:( 1887):( 0016):Record no 0009 SRTIO05:( 1887):( 0006):Record no 0010 SRTIO05:( 1887):( 0015):Record no 0011 SRTIO05:( 1887):( 0005):Record no 0012 SRTIO05:( 1887):( 0014):Record no 0013 SRTIO05:( 1887):( 0013):Record no 0014 SRTIO05:( 1887):( 0004):Record no 0015 SRTIO05:( 1887):( 0003):Record no 0016 SRTIO05:( 1870):( 0012):Record no 0017 SRTIO05:( 1703):( 0002):Record no 0018 SRTIO05:( 0720):( 0011):Record no 0019 SRTIO05:( 0060):( 0001):Record no 0020 [vince@study sortio_tests]$ As for perf06 I get: [vince@study perform_tests]$ htcobol perf06 perf06.cob: Assembler messages: perf06.cob:3: Error: symbol `.LB_QUAL_SECTION_2_0' is already defined perf06.cob:4: Error: symbol `.LE_QUAL_SECTION_2_0' is already defined [vince@study perform_tests]$ I am running gcc v 4.1.1. Any Ideas for these. Vince. |
|
From: David E. <de...@us...> - 2006-12-29 20:42:48
|
Vince Coen wrote: > ... > Now with LD_LIBRARY_PATH set I have run the > test_suite make file and programs. > > The Only failures I get are with srt03, srt05, perf06 > but both srtio03/05 > compile and execute showing the following respectively: > ... > As for perf06 I get: > $ htcobol perf06 > perf06.cob: Assembler messages: > perf06.cob:3: Error: symbol `.LB_QUAL_SECTION_2_0' is already defined > perf06.cob:4: Error: symbol `.LE_QUAL_SECTION_2_0' is already defined > > I am running gcc v 4.1.1. > > Any Ideas for these. It compiles and runs without these problems on GCC 2x - 3x. AFAIK, no tests have been done with GCC 4x. So I can only assume that there are some problems related to the GCC 4x tool-chain, specifically with GAS. Unfortunatly, I do not have access to a system with GCC 4x installed, and thus no way to test this assertion. |
|
From: vince c. <vb...@bt...> - 2006-12-29 14:36:39
|
Hi; On Friday 29 December 2006 07:36, David Essex wrote: > Vince Coen wrote: > > I Have now installed tc .63 but getting a lot of errors. > > Can't run the test_suite without a lot of errors. > > Ditto when compiling hello world. > > Can someone help? > > ... > > When running ./hello > > > > It gives me: > > > > ./hello: error while loading shared libraries: > > libhtcobol.so.0: cannot open > > shared object file: No such file or directory > > This seams to be a very common problem for some reason. > > The linker needs to locate the RT shared library 'libhtcobol.so.0'. > > The TC configure will install to a prefix='/usr/local' by default, so > the shared library 'libhtcobol.so.0' should be located in the > 'usr/local/lib' directory. Yep, its in /usr/local/lib as in: [vince@study ~]$ ls -la /usr/local/lib/libhtcobol.* -rwxr-xr-x 1 root root 152812 Dec 27 22:40 /usr/local/lib/libhtcobol.a* lrwxrwxrwx 1 root root 35 Dec 27 16:22 /usr/local/lib/libhtcobol.so -> /usr/local/lib/libhtcobol.so.0.63.0* lrwxrwxrwx 1 root root 35 Dec 27 16:22 /usr/local/lib/libhtcobol.so.0 -> /usr/local/lib/libhtcobol.so.0.63.0* -rwxr-xr-x 1 root root 153405 Dec 27 16:22 /usr/local/lib/libhtcobol.so.0.63.0* [vince@study ~]$ > > Unfortunatly, some of the distributions do not use the 'usr/local ...' > directories, thus the linker is not set up to search that path. > > So you can you can do either of the following: > > 1) Set the 'LD_LIBRARY_PATH' enviroment variable (bash: export > LD_LIBRARY_PATH=usr/local/lib), which is a temporary solution. Now done that. > 2) Use the 'ldconf' command to add the path to the linker search path. I do not seem to have that command. Where is it from? > 3) Configure TC using the `--prefix=/usr' option, then compile and > install it. have added --prefix=/usr/local > > I need to solve this first before attempting the > > test suite again as most of > > the test produce similar to this: > > ... > > The test suite on version 0.63 is set up to expect to find the compiler, > RTL and resouce files in the source code sub-directories above the > 'test_suite' directory (i.e. ../compiler, ../lib, etc.). > > So it is best to just configure and compiler TC, then run the test suite. > Otherwise, modifications to the perl script are required. Nope, on this you have lost me. I understand the bit about modding the perl script though. > > Hint: Before you run the test suite, remove the RT shared library (and > links) or compile the RTL a static library only. Lost me on this as well. I'm assuming the RT shared libs are similar to MF? Allowing for strong Ram facilities Can I not just compile the whole program to link all required modules and libraries together and would this be the fastest way to load and run? Also using the configure option of MF compatable what exactly does this do? I cannot see any documentation on this or what language set is available in the compiler at this time. Is the CVS version more up to date and reasonably stable or is it best to stick to the archives in the download area? Out of interest what problems would there be to use tc on a 64 bit system i.e., Dual 2 core E6600 using a mandriva x86-64 Linux system install (It uses both 32 and 64 bit libraries? Vince. |
|
From: David E. <de...@us...> - 2006-12-29 23:24:49
|
Vince Coen wrote:
> ...
The problems you have encountered with shared libraries are not TC, or
COBOL, specific.
This is a UN*X administration issue, and chances are that you will
encounter this problem again.
A quick solution is to move the relavent objects from the their
'/usr/local' to the '/usr' sub-directories.
As for running the test_suite perl script, in the 'lib' directory type
'make clean' and then 'make static-libs'.
This should enable you to run the test_suite perl script with out any
modifications.
> ...
> I'm assuming the RT shared libs are similar to MF?
I'm not familiar with MF products, so I can't comment.
> Allowing for strong Ram facilities Can I not just
> compile the whole program to link all required
> modules and libraries together and would this be the
> fastest way to load and run?
I'm not sure what mean.
Have you looked at the 'htcobrun' in the 'cobrun' directory.
> Also using the configure option of MF compatable what
> exactly does this do?
There is only two options, really.
The first relates to the 'ACCEPT identifier FROM COMMAND-LINE' verb.
In UN*X the first command line parameter is always the actual program
name (argv[0]).
Some COBOL compilers do include the program name (ARGV[1] ... argv[n]).
See 'test.code/test17' for an example.
The second relates to the 'SELECT file-name ASSIGN TO EXTERNAL
{identifier | literal}' verb. The 'EXTERNAL' option relates the internal
file-name to actual file-name using environment variables.
Some COBOL compilers add a prefix, such as 'DD_' to the environment
variables.
See 'test.code/test19' for an example.
There is also the 'DISPLAY/ACCEPT LINE/POS' variation, which is MF
specific. But that is always usable.
> I cannot see any documentation on this or what language set
> is available in the compiler at this time.
Well, English only I'm afraid.
There is an configure option for some languages. But even those are
limited to man, command line help files but no run-time.
And even the very limited documentation translations are not very
current, as I could not get any volunteers to do the translations.
> Is the CVS version more up to date and reasonably stable or
> is it best to stick to the archives in the download area?
Well, the CVS version is relatively stable, but there is not much
difference between the CVS and 0.63 versions.
> Out of interest what problems would there be to use tc
> on a 64 bit system
> i.e., Dual 2 core E6600 using a mandriva x86-64 Linux system
> install (It uses both 32 and 64 bit libraries?
I have no idea even if TC will compile an run properly on a 64-bit system.
Personally, I have no plans to do any work on TC for 64-bit systems.
|
|
From: vince c. <vb...@bt...> - 2007-01-04 15:58:11
|
Hi David On Friday 29 December 2006 23:23, David Essex wrote: > > A quick solution is to move the relavent objects from the their > '/usr/local' to the '/usr' sub-directories. > > As for running the test_suite perl script, in the 'lib' directory type > 'make clean' and then 'make static-libs'. > This should enable you to run the test_suite perl script with out any > modifications. > > > Allowing for strong Ram facilities Can I not just > > compile the whole program to link all required > > modules and libraries together and would this be the > > fastest way to load and run? > > I'm not sure what mean. > Have you looked at the 'htcobrun' in the 'cobrun' directory. I mean to link all the program elements / routines / sub programs etc together with all runtime libraries to make a complete running program that can be transferred to any linux system and run as a standalone program. > > I cannot see any documentation on this or what language set > > is available in the compiler at this time. > > Well, English only I'm afraid. I mean here the Cobol Language and syntax as used in Tiny Cobol. I am still not able to run all tests without some failures despite using various versions of gcc including 4.1.1 , 3.3.6 amd 2.96. What is the corrent one to use? Vince. |
|
From: David E. <de...@us...> - 2007-01-04 19:55:54
|
Vince Coen wrote: > David Essex wrote: > ... >> I'm not sure what mean. > > I mean to link all the program elements / routines / > sub programs etc together with all runtime libraries > to make a complete running program that can be > transferred to any linux system and run as a standalone program. I think you mean a completly statically linked program. Yes you can do that, but it is generally not done (on UN*X) except by some system utilities. The only dependencies used by TC programs are TC-RTL, BDB and (n/pd)curses. UN*X: Except for the TC RTL, all other dependencies including BDB and (n)curses, are usually part of the UN*X (Linux/BSD) distribution Distributing binaries on UN*X (especially Linux) can be problematic. But this is not specific to TC, but a very common problem. Win32: The best approach is to create a TC-RTL DLL which includes BDB and PDcurses. Then all TC dependencies are resolved by the TC-RTL DLL. Down side, 3 different licenses in one DLL. On UN*X, you can check the dependencies using the LDD command. > ... > I am still not able to run all tests without some failures > despite using various versions of gcc including 4.1.1 , 3.3.6 > amd 2.96. > What is the corrent one to use? Version 0.63 should compile and run on 32-bit systems using GCC 2.x - 3.x. I have no information about 32-bit (or 64-bit) systems using GCC 4.x. I think the problem you have encountered is related to 64-bit systems. Since I have no experience with 64-bit systems, I really can't help. David Essex |
|
From: vince c. <vb...@bt...> - 2007-01-05 12:28:26
|
Hi; On Thursday 04 January 2007 19:54, David Essex wrote: > > I am still not able to run all tests without some failures > > despite using various versions of gcc including 4.1.1 , 3.3.6 > > amd 2.96. > > What is the corrent one to use? > > Version 0.63 should compile and run on 32-bit systems using GCC 2.x - 3.x. > I have no information about 32-bit (or 64-bit) systems using GCC 4.x. > > I think the problem you have encountered is related to 64-bit systems. > Since I have no experience with 64-bit systems, I really can't help. Nope running in a 32 bit Mandriva environment only. Want to get the basics working first. Vince. |
|
From: David E. <de...@us...> - 2007-01-05 18:35:45
|
I think we need to isolate the problem, so I will require more information. Vince Coen wrote: > David Essex wrote: > >> Vince Coen wrote: >> >>> I am still not able to run all tests without some failures >>> despite using various versions of gcc including 4.1.1 , 3.3.6 >>> amd 2.96. >>> What is the corrent one to use? Well GCC 3.3.6 should work. Do you have 3 GCC versions on one system ? If so, so you have 3 versions of the back end (GAS and Linux linker) ? >> Version 0.63 should compile and run on 32-bit systems >> using GCC 2.x - 3.x. >> I have no information about 32-bit (or 64-bit) systems using >> GCC 4.x. >> >> I think the problem you have encountered is related to 64-bit >> systems. >> Since I have no experience with 64-bit systems, I really can't >> help. > > Nope running in a 32 bit Mandriva environment only. > Want to get the basics working first. When you use GCC version 3.x, do you still get the following errors ? As for perf06 I get: $ htcobol perf06 perf06.cob: Assembler messages: perf06.cob:3: Error: symbol `.LB_QUAL_SECTION_2_0' is already defined perf06.cob:4: Error: symbol `.LE_QUAL_SECTION_2_0' is already defined Actually could you try the following command and list the output. $htcobol -v perf06.cob If the above problem persists, issue the following command and send me (not the list) the assembler file in a ZIP or TAR/GZ archive. $htcobol -v -S perf06.cob David Essex |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X