[Bug-GnuCOBOL] using separately-compiled user-defined functions

[James K. Lowden]

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.