Menu
▾
▴
tiny-cobol-users
|
From: Reg <re...@ri...> - 2007-10-28 12:31:39
|
David, Please accept my apologies for not following up on this yet. I simply cannot find the time at the moment, but expect to get back to it in about 2 weeks. Regards, R. -- View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a13452878 Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: David E. <de...@us...> - 2007-10-28 22:29:29
|
Reg wrote: > David, Please accept my apologies for > not following up on this yet. > I simply cannot find the time at the moment, > but expect to get back to it in about 2 weeks. No rush. Please use the latest CVS version, currently at 0.63.83, as it should be more stable. Cheers |
|
From: Reg <re...@ri...> - 2007-12-04 18:57:08
|
Hi David, Have at last found some time, downloaded 0.63.87 and installed, compilation worked! Haven't got any further than that for the moment, just thought I would let you know. Will try out on some bigger programs soon. Thanks for your efforts. Regards, Reg. David Essex-2 wrote: > > Reg wrote: > > > David, Please accept my apologies for > > not following up on this yet. > > I simply cannot find the time at the moment, > > but expect to get back to it in about 2 weeks. > > No rush. > > Please use the latest CVS version, currently at 0.63.83, as it should be > more stable. > > > Cheers > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Tin...@li... > https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users > > -- View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14156953 Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: Reg <re...@ri...> - 2007-12-06 14:13:26
|
Hi David, Compilation worked for option -m but using option -x got:- [root@Appserver development]# htcobol -x /TinyCat/DEGRABBER.COB DEGRABBER.o: In function `DEGRABBER': DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq' DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx' DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq' collect2: ld returned 1 exit status [root@Appserver development]# These are references to index sequential read, write and read next. Any ideas? Regards, Reg. Reg wrote: > > Hi David, > Have at last found some time, downloaded 0.63.87 and installed, > compilation worked! > Haven't got any further than that for the moment, just thought I would let > you know. > Will try out on some bigger programs soon. > Thanks for your efforts. > Regards, > Reg. > > David Essex-2 wrote: >> >> Reg wrote: >> >> > David, Please accept my apologies for >> > not following up on this yet. >> > I simply cannot find the time at the moment, >> > but expect to get back to it in about 2 weeks. >> >> No rush. >> >> Please use the latest CVS version, currently at 0.63.83, as it should be >> more stable. >> >> >> Cheers >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Tin...@li... >> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users >> >> > > -- View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14192838 Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: David E. <de...@us...> - 2007-12-07 07:06:38
|
Reg wrote: > Compilation worked for option -m but using option -x got:- > > # htcobol -x /TinyCat/DEGRABBER.COB > DEGRABBER.o: In function `DEGRABBER': > DEGRABBER.COB:(.text+0x662): > undefined reference to `tcob_read_next_seq' > DEGRABBER.COB:(.text+0xa31): > undefined reference to `tcob_write_idx' > DEGRABBER.COB:(.text+0xd40): > undefined reference to `tcob_read_next_seq' > collect2: ld returned 1 exit status > > These are references to index sequential read, write and read next. > Any ideas? This is a linkage problem. The module creation option '-m' would not produce any errors because the linkage is done at run time. For some reason, the above functions were not found in the TC RTL, or the TC library 'libhtcobol.a' was not found in the library paths. I suspect that the TC RT library 'libhtcobol.a' was not found. To confirm that the path is the problem, add the verbose option '-v' to the command line. Example: $htcobol -v -x t71202a.cob as -o t71202a.o t71202a.s gcc -o t71202a t71202a.o -L/usr/lib -lhtcobol -ldb1 -lncurses -ldl -lm Or you could run the commands individually. Example: $htcobol -v -c t71202a.cob as -o t71202a.o t71202a.s $gcc -o t71202a t71202a.o -L/usr/lib -lhtcobol -ldb1 -lncurses -ldl -lm Hope this helps. Cheers |
|
From: Reg <re...@ri...> - 2007-12-07 11:30:35
|
Hi David, As you suspected, the following:- [root@Appserver TinyCat]# htcobol -v -x /TinyCat/DEGRABBER.COB as -o DEGRABBER.o DEGRABBER.s gcc -o DEGRABBER DEGRABBER.o -L/usr/local/lib -lhtcobol -ldl -ldb -lncurses -lm DEGRABBER.o: In function `DEGRABBER': DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq' DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx' DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq' collect2: ld returned 1 exit status [root@Appserver TinyCat]# as -o DEGRABBER.o DEGRABBER.s Assembler messages: Error: can't open DEGRABBER.s for reading: No such file or directory [root@Appserver TinyCat]# htcobol -v -c /TinyCat/DEGRABBER.COB as -o DEGRABBER.o DEGRABBER.s [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib -lhtcobol -ldb1 -lncurses -ldl -lm /usr/bin/ld: cannot find -ldb1 collect2: ld returned 1 exit status [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib -lhtcobol -lncurses -ldl -lm -ldb1 /usr/bin/ld: cannot find -ldb1 collect2: ld returned 1 exit status [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib -lhtcobol -lncurses -ldl -lm DEGRABBER.o: In function `DEGRABBER': DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq' DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx' DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq' collect2: ld returned 1 exit status [root@Appserver TinyCat]# find / -name db1 -print [root@Appserver TinyCat]# -- View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14210829 Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: Reg <re...@ri...> - 2007-12-07 13:01:36
|
Sorry, last two lines should have read:- find / -name db1 -print /usr/include/db1 i.e. db1 is installed, and so is db4 For some reason, the linker cannot find db1 (or db4 if it is substituted). The htcobol config had no entry for --with-libdb= Could it be that the OS is Fedora rather than RedHat? Just downloaded the RPM, didn't compile from source for the development version. Regs, Reg. Reg wrote: > > > Hi David, > As you suspected, the following:- > > [root@Appserver TinyCat]# htcobol -v -x /TinyCat/DEGRABBER.COB > as -o DEGRABBER.o DEGRABBER.s > gcc -o DEGRABBER DEGRABBER.o -L/usr/local/lib -lhtcobol -ldl -ldb > -lncurses -lm > DEGRABBER.o: In function `DEGRABBER': > DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq' > DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx' > DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq' > collect2: ld returned 1 exit status > [root@Appserver TinyCat]# as -o DEGRABBER.o DEGRABBER.s > Assembler messages: > Error: can't open DEGRABBER.s for reading: No such file or directory > [root@Appserver TinyCat]# htcobol -v -c /TinyCat/DEGRABBER.COB > as -o DEGRABBER.o DEGRABBER.s > [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib > -lhtcobol -ldb1 -lncurses -ldl -lm > /usr/bin/ld: cannot find -ldb1 > collect2: ld returned 1 exit status > [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib > -lhtcobol -lncurses -ldl -lm -ldb1 > /usr/bin/ld: cannot find -ldb1 > collect2: ld returned 1 exit status > [root@Appserver TinyCat]# gcc -o DEGRABBER DEGRABBER.o -L/usr/lib > -lhtcobol -lncurses -ldl -lm > DEGRABBER.o: In function `DEGRABBER': > DEGRABBER.COB:(.text+0x662): undefined reference to `tcob_read_next_seq' > DEGRABBER.COB:(.text+0xa31): undefined reference to `tcob_write_idx' > DEGRABBER.COB:(.text+0xd40): undefined reference to `tcob_read_next_seq' > collect2: ld returned 1 exit status > [root@Appserver TinyCat]# find / -name db1 -print > [root@Appserver TinyCat]# > -- View this message in context: http://www.nabble.com/Segmentation-Fault-tf4383688.html#a14211946 Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: David E. <de...@us...> - 2007-12-07 16:47:06
|
Reg wrote: > As you suspected, the following:- > > #htcobol -v -x /TinyCat/DEGRABBER.COB > as -o DEGRABBER.o DEGRABBER.s > gcc -o DEGRABBER DEGRABBER.o -L/usr/local/lib -lhtcobol > -ldl -ldb -lncurses -lm > DEGRABBER.o: In function `DEGRABBER': > DEGRABBER.COB:(.text+0x662): > undefined reference to `tcob_read_next_seq' > ... > collect2: ld returned 1 exit status Since there is no error message '/usr/bin/ld: cannot find -lhtcobol', then it must be another version of the TC RTL, not version 0.63.87. Check the 'develoment/lib' directory to see if the RTL compiled properly (check for a file called libhtcobol.a). If the library file exists, run the following, manually. #htcobol -v -c /TinyCat/DEGRABBER.COB as -o DEGRABBER.o DEGRABBER.s #gcc -o DEGRABBER DEGRABBER.o -L/somepath/development/lib -lhtcobol \ -ldb -lncurses -ldl -lm Here the 'somepath' is the location where the TC source code is located. If the compilation succeded, check that all libraries are found. #ldd DEGRABBER > ... > Sorry, last two lines should have read:- > find / -name db1 -print > /usr/include/db1 > > i.e. db1 is installed, and so is db4 > For some reason, the linker cannot find db1 (or db4 if it is > substituted). > The htcobol config had no entry for --with-libdb= > Could it be that the OS is Fedora rather than RedHat? > Just downloaded the RPM, didn't compile from source for > the development version. All RPM based sytems have multiple versions of BDB installed. They also use soft links, making it difficult to determine which library is actually used when '-ldb' is used in a link step. TC uses the BDB 1.85 API, which is supported in all versions of BDB, up to (and including) 4x (4.4 I think). In any case the 'configure' script checks what is installed and if it works. So if the 'configure' step worked, don't worry about it for the time being. Hope this helps. Cheers |
|
From: Reg <re...@ri...> - 2007-12-11 23:48:10
|
Hi David, followed your suggestion:-
[root@Appserver development]# htcobol -v -c /TinyCat/DEGRABBER.COBas -o
DEGRABBER.o DEGRABBER.s
[root@Appserver development]# gcc -o DEGRABBER DEGRABBER.o
-L/TinyCobol/development/lib -lhtcobol -ldb -lncurses -ldl -lm
[root@Appserver development]# ldd DEGRABBER
linux-gate.so.1 => (0x00110000)
libdb-4.3.so => /lib/libdb-4.3.so (0x05479000)
libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00a7c000)
libdl.so.2 => /lib/libdl.so.2 (0x00db4000)
libm.so.6 => /lib/libm.so.6 (0x00d8b000)
libc.so.6 => /lib/libc.so.6 (0x00c49000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00dd7000)
/lib/ld-linux.so.2 (0x00c2c000)
[root@Appserver development]#
I'm not sure what this is telling me, except that it seems to want
libdb-4.3.so and I config'd htcobol without the db option at all, never mind
db4, so it should have defaulted to 1.
Do you think I should clean the computer off and reinstall from scratch, as
I have 4 htcobol implementations on it at present?
Regs.
Reg.
--
View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14286155.html
Sent from the tiny-cobol-users mailing list archive at Nabble.com.
|
|
From: David E. <de...@us...> - 2007-12-12 14:37:19
|
Reg wrote: > ... followed your suggestion:- > #htcobol -v -c /TinyCat/DEGRABBER.COB > as -o DEGRABBER.o DEGRABBER.s > #gcc -o DEGRABBER DEGRABBER.o > -L/TinyCobol/development/lib -lhtcobol > -ldb -lncurses -ldl -lm No 'undefined reference ...' linkage error messages. Then one can assume that the correct version of the TC RTL was used. > #ldd DEGRABBER > linux-gate.so.1 => ... (0x00110000) > libdb-4.3.so => /lib/libdb-4.3.so (0x05479000) > libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00a7c000) > libdl.so.2 => /lib/libdl.so.2 (0x00db4000) > libm.so.6 => /lib/libm.so.6 (0x00d8b000) > libc.so.6 => /lib/libc.so.6 (0x00c49000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00dd7000) > .., /lib/ld-linux.so.2 (0x00c2c000) > > I'm not sure what this is telling me, except that it seems > to want libdb-4.3.so and I config'd htcobol without the db > option at all, never mind db4, so it should have defaulted to 1. The 'ldd' command shows the shared libraries dependencies and their location (if found), for binary DEGRABBER. Note that 'ldd' did not list '-lhtcobol' (libhtcobol.a), or any static library (archive) used in the link. In this case 'DEGRABBER' was linked with '/lib/libdb-4.3.so', meaning BDB 4.3. But the compile command used '-ldb', meaning that 'libdb.so' is a soft link to some other library or link. This is not a problem as the BDB 1.85 API is included in version 4.3. > Do you think I should clean the computer off and re-install > from scratch, as I have 4 htcobol implementations on it at > present? No UN*X is NOT MS windows, and a clean re-install should not be necessary. Well, unless you corrupted the RPM database (BDB). But the RPM utilities will usually prevent any one from doing so. You can have as many versions of TC installed as you wish. Managing this situation however can be problematic. How to remove TC from your system depends on how it was installed. If for example an RPM (DEB ...) was used, use the RPM utilities to un-install TC. If installed from source (... make install), then locate (whereis, find) and remove the binaries (htcobol, htcobrun), library and config directory. If both methods were used, this can be problematic as the integrity of the RPM database needs to be maintained. Maybe if both removal methods were used, RPM first. Personally, I usually have two versions (sometimes more) on my system. The current release, and the CVS version. Since I don't run any production programs, I usually do not install TC. If I do, I rename the binaries, library and config directory, to ensure no conflicts. I prefer to work with TC from some '/home/user/somepath' directory and set the environment variables (PATH, TCOB_OPTIONS_PATH, TCOB_RTCONFIG_PATH) make files as required. Anyway, hope this helps. Cheers. |
|
From: Reg <re...@ri...> - 2007-12-12 18:35:50
|
Hi David, This now works to create a static binary, but how do I create a dynamic loading system? When I change the -c to -x on the compile stage, I get the problem again. What do I need to put in on the compile line? (htcobol ......-x or -m.....XYZ.COB) Thanks again. Reg. David Essex-2 wrote: > > Reg wrote: > > ... followed your suggestion:- > > #htcobol -v -c /TinyCat/DEGRABBER.COB > > as -o DEGRABBER.o DEGRABBER.s > > #gcc -o DEGRABBER DEGRABBER.o > > -L/TinyCobol/development/lib -lhtcobol > > -ldb -lncurses -ldl -lm > > No 'undefined reference ...' linkage error messages. > Then one can assume that the correct version of the TC RTL was used. > > > #ldd DEGRABBER > > linux-gate.so.1 => ... (0x00110000) > > libdb-4.3.so => /lib/libdb-4.3.so (0x05479000) > > libncurses.so.5 => /usr/lib/libncurses.so.5 (0x00a7c000) > > libdl.so.2 => /lib/libdl.so.2 (0x00db4000) > > libm.so.6 => /lib/libm.so.6 (0x00d8b000) > > libc.so.6 => /lib/libc.so.6 (0x00c49000) > > libpthread.so.0 => /lib/libpthread.so.0 (0x00dd7000) > > .., /lib/ld-linux.so.2 (0x00c2c000) > > > > I'm not sure what this is telling me, except that it seems > > to want libdb-4.3.so and I config'd htcobol without the db > > option at all, never mind db4, so it should have defaulted to 1. > > The 'ldd' command shows the shared libraries dependencies and their > location (if found), for binary DEGRABBER. > > Note that 'ldd' did not list '-lhtcobol' (libhtcobol.a), or any static > library (archive) used in the link. > > In this case 'DEGRABBER' was linked with '/lib/libdb-4.3.so', meaning > BDB 4.3. But the compile command used '-ldb', meaning that 'libdb.so' is > a soft link to some other library or link. > This is not a problem as the BDB 1.85 API is included in version 4.3. > > > Do you think I should clean the computer off and re-install > > from scratch, as I have 4 htcobol implementations on it at > > present? > > No UN*X is NOT MS windows, and a clean re-install should not be necessary. > Well, unless you corrupted the RPM database (BDB). > But the RPM utilities will usually prevent any one from doing so. > > You can have as many versions of TC installed as you wish. > Managing this situation however can be problematic. > > How to remove TC from your system depends on how it was installed. > If for example an RPM (DEB ...) was used, use the RPM utilities to > un-install TC. > If installed from source (... make install), then locate (whereis, find) > and remove the binaries (htcobol, htcobrun), library and config directory. > If both methods were used, this can be problematic as the integrity of > the RPM database needs to be maintained. > Maybe if both removal methods were used, RPM first. > > Personally, I usually have two versions (sometimes more) on my system. > The current release, and the CVS version. > > Since I don't run any production programs, I usually do not install TC. > If I do, I rename the binaries, library and config directory, to ensure > no conflicts. > I prefer to work with TC from some '/home/user/somepath' directory and > set the environment variables (PATH, TCOB_OPTIONS_PATH, > TCOB_RTCONFIG_PATH) make files as required. > > Anyway, hope this helps. > > Cheers. > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Tin...@li... > https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users > > -- View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14301033.html Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: David E. <de...@us...> - 2007-12-13 02:27:29
|
Reg wrote:
> This now works to create a static binary, but
> how do I create a dynamic loading system?
What was created in the example was a binary linked with shared
libraries (DLL's) and a static TC RT library.
The system linker will try to use a shared library, failing that it will
try using a static library.
So I'm not sure what you mean by a 'dynamic loading system'.
If you want to create a shared TC RT library (DLL), just change the
'lib' make file.
#all: static-libs
all: static-libs shared-libs
...
#install: install-rts-config install-static-libs
install: install-rts-config install-static-libs install-shared-libs
Then from the 'development' directory,
make clean
make
make install (as root)
If you prefer to use modules (shared library), just use the '-m' option
then run it using 'htcobrun'.
> When I change the -c to -x on the compile stage,
> I get the problem again.
> What do I need to put in on the compile line?
> (htcobol ......-x or -m.....XYZ.COB)
The reason you are getting those linkage error messages, is that you are
using two different versions of TC to create a binary.
You are using 'htcobol' from version 0.63.87 (I think), and the RTL from
another TC version.
The best fix would be to remove all installed TC files, then do a new TC
install using the source from version 0.63.87.
A quich fix is to use add the following to the xterm config ('.bashrc'
or '.profile'), or what ever you are using as a terminal.
export TCOB_OPTIONS_PATH=/TinyCobol/development/compiler
export TCOB_RTCONFIG_PATH=/TinyCobol/development/lib
export TCOB_LD_LIBRARY_PATH=/TinyCat
export LD_LIBRARY_PATH=/TinyCobol/development/lib:/TinyCat
To the TC compile time resource file 'htcobolrc', found in the
'development/compiler' directory, add the following.
LD_PATH: -L/TinyCobol/development/lib
Now do the following.
Check the version of TC used, a test compile and run the binary created.
You should get the following results with no linker errors.
#/TinyCobol/development/compiler/htcobol -V
TinyCOBOL - pre alpha 0.63.87 ...
#cd /TinyCat
#/TinyCobol/development/compiler/htcobol -v -x DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
gcc -o DEGRABBER DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
-ldl -ldb -lncurses -lm
#./DEGRABBER
Now create a module and use 'htcobrun' to load it and run it.
#/TinyCobol/development/compiler/htcobol -v -m DEGRABBER.COB
as -o DEGRABBER.o DEGRABBER.s
gcc -shared -Wl,-soname,DEGRABBER.so -o DEGRABBER.so
DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
#/TinyCobol/development/cobrun/htcobrun DEGRABBER
Cheers.
|
|
From: Reg <re...@ri...> - 2007-12-14 22:39:12
|
Hi David,
Decided to get rid of all the clutter, removed all versions of TC and
re-installed from CVS.
Compilations worked perfectly.
Thanks.
Next problem:-
Whether I compile with -m and run vis htcobrun or compile with -x for an
executable,
when I call the next program in the system I get:-
/TinyCat/startpass1: line 4: 13359 Segmentation fault
/TinyCobol/development/cobrun/htcobrun PASSCHEC1
(different number for fault from -x version).
This seems to occur when PASSCHEC1 calls the next program, which was
compiled with -m.
Could be the next program is large or the single parameter passed in linkage
is too big?
Anyway, seems like a memory fault similar to the compile problem prior to
the CVS version.
Regards,
Reg.
David Essex-2 wrote:
>
> Reg wrote:
>
> > This now works to create a static binary, but
> > how do I create a dynamic loading system?
>
> What was created in the example was a binary linked with shared
> libraries (DLL's) and a static TC RT library.
> The system linker will try to use a shared library, failing that it will
> try using a static library.
>
> So I'm not sure what you mean by a 'dynamic loading system'.
>
> If you want to create a shared TC RT library (DLL), just change the
> 'lib' make file.
>
> #all: static-libs
> all: static-libs shared-libs
> ...
> #install: install-rts-config install-static-libs
> install: install-rts-config install-static-libs install-shared-libs
>
> Then from the 'development' directory,
> make clean
> make
> make install (as root)
>
> If you prefer to use modules (shared library), just use the '-m' option
> then run it using 'htcobrun'.
>
> > When I change the -c to -x on the compile stage,
> > I get the problem again.
> > What do I need to put in on the compile line?
> > (htcobol ......-x or -m.....XYZ.COB)
>
> The reason you are getting those linkage error messages, is that you are
> using two different versions of TC to create a binary.
> You are using 'htcobol' from version 0.63.87 (I think), and the RTL from
> another TC version.
>
> The best fix would be to remove all installed TC files, then do a new TC
> install using the source from version 0.63.87.
>
> A quich fix is to use add the following to the xterm config ('.bashrc'
> or '.profile'), or what ever you are using as a terminal.
>
> export TCOB_OPTIONS_PATH=/TinyCobol/development/compiler
> export TCOB_RTCONFIG_PATH=/TinyCobol/development/lib
> export TCOB_LD_LIBRARY_PATH=/TinyCat
> export LD_LIBRARY_PATH=/TinyCobol/development/lib:/TinyCat
>
> To the TC compile time resource file 'htcobolrc', found in the
> 'development/compiler' directory, add the following.
>
> LD_PATH: -L/TinyCobol/development/lib
>
> Now do the following.
> Check the version of TC used, a test compile and run the binary created.
> You should get the following results with no linker errors.
>
> #/TinyCobol/development/compiler/htcobol -V
> TinyCOBOL - pre alpha 0.63.87 ...
>
> #cd /TinyCat
>
> #/TinyCobol/development/compiler/htcobol -v -x DEGRABBER.COB
> as -o DEGRABBER.o DEGRABBER.s
> gcc -o DEGRABBER DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
> -ldl -ldb -lncurses -lm
>
> #./DEGRABBER
>
> Now create a module and use 'htcobrun' to load it and run it.
>
> #/TinyCobol/development/compiler/htcobol -v -m DEGRABBER.COB
> as -o DEGRABBER.o DEGRABBER.s
> gcc -shared -Wl,-soname,DEGRABBER.so -o DEGRABBER.so
> DEGRABBER.o -L/TinyCobol/development/lib -lhtcobol
>
> #/TinyCobol/development/cobrun/htcobrun DEGRABBER
>
> Cheers.
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
>
>
--
View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14339835.html
Sent from the tiny-cobol-users mailing list archive at Nabble.com.
|
|
From: David E. <de...@us...> - 2007-12-15 19:09:53
|
Reg wrote: > Next problem:- > Whether I compile with -m and run vis htcobrun or > compile with -x for an executable, > when I call the next program in the system I get:- > > /TinyCat/startpass1: line 4: 13359 Segmentation fault > /TinyCobol/development/cobrun/htcobrun PASSCHEC1 > > (different number for fault from -x version). > This seems to occur when PASSCHEC1 calls the next > program, which was compiled with -m. > Could be the next program is large or the single > parameter passed in linkage is too big? > Anyway, seems like a memory fault similar to the > compile problem prior to the CVS version. I don't have sufficient information to determine the problem. But usually a 'segmentation fault' with a CALL statement usually occurs when the input/output paramaters are not in sync. Or when a dynamic call fails and input/output paramater data contains junk. Did you set the following 'environment variables' ? export TCOB_LD_LIBRARY_PATH=/TinyCat export LD_LIBRARY_PATH=/TinyCat Hint: You can check a call statement with the following code. CALL ... ON EXCEPTION ... Cheers. |
|
From: Reg <re...@ri...> - 2007-12-22 16:45:48
|
Hi David, After messing around with various alternatives, I decided that passing multiple large linkage parameters from program to program was too flakey, so now write them to a file and read them with single programs each compiled with -x and running separately. Works fine, segmentation errors gone. Problem now is that lockserver doesn't work. Set lockserver running in -d mode, comes up with messages ending with "Server socket set-up" so seems to be running fine. Re-did Tiny Cobol config in development directory with --enable-lockserv, make, make install. Seems to completely ignore the option. No reference to it in config.log, compiler chucks out error message on encountering "unlock" (undefined reference to tcob_unlock), no locking taking place on "read with lock" according to lockserver debug, no lock (status 51) encountered when expected in programs.. What am I doing wrong? Regards, Reg. PS Sorry to hear that you intend to "retire" from the TC project next year, but I guess you have done more than your share........ I for one am grateful for your efforts. Thanks. Reg. David Essex-2 wrote: > > Reg wrote: > > > Next problem:- > > Whether I compile with -m and run vis htcobrun or > > compile with -x for an executable, > > when I call the next program in the system I get:- > > > > /TinyCat/startpass1: line 4: 13359 Segmentation fault > > /TinyCobol/development/cobrun/htcobrun PASSCHEC1 > > > > (different number for fault from -x version). > > This seems to occur when PASSCHEC1 calls the next > > program, which was compiled with -m. > > Could be the next program is large or the single > > parameter passed in linkage is too big? > > Anyway, seems like a memory fault similar to the > > compile problem prior to the CVS version. > > I don't have sufficient information to determine the problem. > > But usually a 'segmentation fault' with a CALL statement usually occurs > when the input/output paramaters are not in sync. > Or when a dynamic call fails and input/output paramater data contains > junk. > > Did you set the following 'environment variables' ? > > export TCOB_LD_LIBRARY_PATH=/TinyCat > export LD_LIBRARY_PATH=/TinyCat > > Hint: > You can check a call statement with the following code. > CALL ... ON EXCEPTION ... > > Cheers. > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Tin...@li... > https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users > > -- View this message in context: http://www.nabble.com/Segmentation-Fault-tp12496784p14471041.html Sent from the tiny-cobol-users mailing list archive at Nabble.com. |
|
From: David E. <de...@us...> - 2007-12-23 01:06:25
|
Reg wrote: > After messing around with various alternatives, > I decided that passing multiple large linkage > parameters from program to program was too flakey, > so now write them to a file and read them with > single programs each compiled with -x and running > separately. > Works fine, segmentation errors gone. I do not understand what kind of problem you have encountered, or what you mean by 'large linkage parameters' (100KB, 1MB). In any case, if you are passing the linkage parameters BY REFERENCE, which is the default, you are only passing a pointer (4 bytes on 32bit systems). I ran some tests using both the '-x' and '-m' options, but I did not encounter any problems. > Problem now is that lockserver doesn't work. > Set lockserver running in -d mode, comes up with > messages ending with "Server socket set-up" so > seems to be running fine. > Re-did Tiny Cobol config in development directory > with --enable-lockserv, make, make install. > Seems to completely ignore the option. No reference > to it in config.log, compiler chucks out error > message on encountering "unlock" (undefined reference > to tcob_unlock), no locking taking place on "read with > lock" according to lockserver debug, no lock (status 51) > encountered when expected in programs.. > What am I doing wrong? Well 'lockserver' is not currently supported by the run-time. If you run './configure --help' you will notice that it is no longer an option. I had planned to replace 'lockserver' with 'MONTSUQI'(1). It is a small transaction monitor which, according to the web site, works with OC. Except for 'lockserver', file LOCKS were badly implemented on TC, for the following reasons. 1) File LOCKS are not defined in the COBOL-85 standard. 2) Inconsistent behavior between different file types. 3) File LOCKS (flock) are not supported by the BDB 185 API. ... There are more reasons, but suffice it to say that some sort of transaction server would be the best way to ensure data integrity. In any case, I had no plans to support file LOCKS considering the above reasons. I will reconsider support for file LOCKS for indexed file types only, using either 'lockserver' or 'MONTSUQI'. But first I need to finish what I started, run-time support for SORT. So it may be a while before I can look at the code. > PS Sorry to hear that you intend to "retire" from the > TC project next year, but I guess you have done more > than your share........ I for one am grateful for your > efforts. IMHO, except for the SCREEN (ACCEPT/DISPLAY) IO code and being Win32 friendly, OC has surpassed TC. So I don't see the benefit of developing two COBOL compilers. Cheers 1) MONTSUQI (Panda) - transaction monitor http://www.nurs.or.jp/~ogochan/panda/ |
|
From: David E. <de...@us...> - 2007-12-26 03:29:59
|
David Essex wrote: > Reg wrote: > Problem now is that lockserver doesn't work. > ... >> Well 'lockserver' is not currently supported by the run-time. >> ... >> I will reconsider support for file LOCKS for indexed file >> types only, using either 'lockserver' or 'MONTSUQI'. Upon further consideration I will not add support for 'lockserver' to the run-time. The principal reason is that file LOCKS (flock) are not supported by the BDB 185 API. AFAIK, there is no way to ensure data integrity of the index file. As for 'MONTSUQI', I can't read Japanese, but it does not appear to support Win32. Unfortunately, this means version 0.64 of TC will not support file LOCKS. Cheers |
×
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