GNuCOBOL & c-tree DB via EXTFH

[Sebastian Steinweg]

Hi,

we are trying to run GNUCOBOL with c-tree file system instead of default BDB on linux 64 bit system using version 3.1.2.0 of GnuCOBOL.

In the Getting started we found an option -fcallfh to set a name to be used for I/O as external provided EXTFH interface module.

c-tree itself delivers an EXTFH file in form of a .so with name CTEXTFH.so file or in form of a .a file.

Known from other compiler the .so file should work.

We set up the following:

1. export LD_LIBRARY_PATH to the PATH were the .so file is stored
2. compile command:

cobc -x -fcallfh=CTEXTFH benchmark.cbl

error:

cobc -x -fcallfh=CTEXTFH benchmark.cbl
/usr/bin/ld: /tmp/cob24573_0.o: in function `benchmark_':
cob24573_0.c:(.text+0x319): undefined reference to `CTEXTFH'
/usr/bin/ld: cob24573_0.c:(.text+0x8a3): undefined reference to `CTEXTFH'
/usr/bin/ld: cob24573_0.c:(.text+0x986): undefined reference to `CTEXTFH'
/usr/bin/ld: cob24573_0.c:(.text+0xa21): undefined reference to `CTEXTFH'
/usr/bin/ld: cob24573_0.c:(.text+0xab8): undefined reference to `CTEXTFH'
/usr/bin/ld: /tmp/cob24573_0.o:cob24573_0.c:(.text+0xb6d): more undefined references to `CTEXTFH' follow
collect2: error: ld returned 1 exit status

If we using no -x in the compile command no error is shown and a benchmark.so is produced, but showing a error while runtime:

cobc -fcallfh=CTEXTFH benchmark.cbl
gnucobol@gnucobol:/home/gnucoboltestv3/test2$ cobcrun -M benchmark benchmark
libcob: Error: entry point 'benchmark' not found

Using EXTFH instead CTEXTFH works fine and generates no error. So we guess we need to set the information to find our CTEXTFH file maybe with help of -L/home/gnucobol/c-treeRTG-Cobol.linux.x64.64bit.v3.0.0.144/drivers/ctree.cobol/extfh option, but the result is the same.

benchmark.cbl -L/home/gnucobol/c-treeRTG-Cobol.linux.x64.64bit.v3.0.0.144/drivers/ctree.cobol/extfh

Using cobc -x -fcallfh=CTEXTFH.so generates another error:

 cobc -x -fcallfh=CTEXTFH.so benchmark.cbl
/tmp/cob25112_0.c:29:19: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
   29 | extern int CTEXTFH.so (unsigned char *opcode, FCD3 *fcd);
      |                   ^
/tmp/cob25112_0.c: In function ‘benchmark_’:
/tmp/cob25112_0.c:315:19: error: ‘CTEXTFH’ undeclared (first use in this function); did you mean ‘EXTFH’?
  315 |   cob_extfh_open (CTEXTFH.so, h_ARK_BENCH, 2, 0, &f_15);
      |                   ^~~~~~~
      |                   EXTFH
/tmp/cob25112_0.c:315:19: note: each undeclared identifier is reported only once for each function it appears in

In another issue of this forum we see that another EXTFH test works using .o files, but this does not help us solving our problem with the .so

Maybe you got an idea what we doing wrong or what we forget to set in our testcase.

PS: With standard BDB file system the program compiles and run fine.

If you need sample files, we can attach them.

Kind regards

Sebastian Steinweg
EasiRun Europa

[Simon Sobisch]

As you internally static link with -fcallfh=CTEXTFH (there is on open request to allow dynamic linking) you need to pass the library, too.

I guess that would be:

cobc -x -fcallfh=CTEXTFH benchmark.cbl -L/home/gnucobol/c-treeRTG-Cobol.linux.x64.64bit.v3.0.0.144/drivers/ctree.cobol/extfh -lCTEXTFH (you possibly have to adjust the -l parameter to match the library name where the CREXTFH entry point is found),

[Sebastian Steinweg]

Thank you for the hint.

we link the static .a ibrary, but it was also neccessary to link some more libraryies from system and c-tree to our command:

cobc -x -fcallfh=CTEXTFH benchmark.cbl -L/home/gnucobol/c-treeRTG-Cobol.linux.x64.64bit.v3.0.0.144/drivers/ctree.cobol/extfh/client.singlethreaded.static -L/home/gnucobol/c-treeRTG-Cobol.linux.x64.64bit.v3.0.0.144/drivers/ctree.drivers/lib/License.Lib/openssl/lib64 -lctextfh -ldl -lm -lssl -lcrypto

With these command we are now able to combine GnuCOBOL & c-tree. The data was placed correctly into the DB!

[Simon Sobisch]

Sounds good, so the next thing is to deep-check if everything works as expected, including different formats (fixed/variable record), datatypes, locking. If you have an update on the test results another post would be appreciated.