[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-GnuCOBOL] using separately-compiled user-defined functions
From: |
James K. Lowden |
Subject: |
[Bug-GnuCOBOL] using separately-compiled user-defined functions |
Date: |
Thu, 16 Aug 2018 01:18:24 -0400 |
I had some difficulty understanding from the manual how to call a
separately compiled user-defined function. I have it working now, but
think I have found a bug. No matter what I do, the cobol runtime
library searches only two places for my function:
1. /usr/local/lib/gnucobol
2. the current working directory
Some particulars:
$ cobc -v
cobc (GnuCOBOL) 3.0-rc1.0
Built Jun 14 2018 19:00:52 Packaged Apr 22 2018 22:26:37 UTC
C version "5.4.0 20160609"
My function:
identification division.
function-id. HelloWorld.
data division.
linkage section.
01 prim-parm-count usage is binary-long.
procedure division returning prim-parm-count.
display "Hello World!".
move 0 to prim-parm-count.
goback.
end function HelloWorld.
compiled as:
$ cobc -m -free -o HELLOWORLD.so func/hello.cbl
Notes:
1. uppercase required
2. current working directory required
My calling program calls my function this way:
PROCEDURE DIVISION USING foo.
OPEN OUTPUT std-pgm-output
display HelloWorld().
No special cobc options to compile the calling program.
Until I put HELLOWORLD.so in the current working directory, I
consistently saw the error message:
libcob: user-defined FUNCTION 'HELLOWORLD' not found
Running strace(1) revealed why:
707:27046 access("./HELLOWORLD.so", R_OK)
= -1 ENOENT (No such file or directory)
708:27046 access("/usr/local/lib/gnucobol/HELLOWORLD.so", R_OK)
= -1 ENOENT (No such file or directory)
710:27046 write(2, "user-defined FUNCTION 'HELLOWORL"..., 44) = 44
A quick search of the compiler sources turned up no direct calls to
access(2); I assume it's implicit in dlopen(3). Evidently dlopen is
being called with "./" prepended to the file name. If just the name
were provided (no "./"), the runtime linker would follow its
path-search algorithm. By specifying the path, the search is defeated.
The manual says that LD_LIBRARY_PATH can be used to specify a search
path for cobol modules. I do not believe that to be true.
In any case, LD_LIBRARY_PATH should be the last resort: it is the
variable that coerces the runtime linker into finding a library
outside its configured search path. That's considered a security
weakness because unprivleged users can introduce (potentially
malicious) libraries. Better to rely on the RPATH, and to give
users a convenient way to set the RPATH in the executable.
If the above analysis is correct, may I suggest:
1. Do not coerce the searched name to be upper case. Rely on the
symbol as presented in the source code, verbatim.
2. Do not prefix the filename with "./" when searching for it. Let
ld.so do its thing.
3. Make RPATH more convenient to set.
4. Update the manual to explain better how to make and use a
separately compiled user-defined function.
--jkl
P.S.: Simon, I'm submitting this on bug-gnucobol@ because I think it is a bug
and I'm discussing improvements to the compiler. Apologies if I overlooked the
place where control of the search path is explained in the manual.
- [Bug-GnuCOBOL] using separately-compiled user-defined functions,
James K. Lowden <=