Using Shared Libraries From ACUCOBOL-GT® on UNIX Systems

April 4, 2002
Acucorp Technical Support

When a COBOL program needs to make use of a routine written in another language (typically C) users of ACUCOBOL-GT have generally needed to update the COBOL runtime by re-linking it to include the new routines. With Version 5.2 of ACUCOBOL-GT, Acucorp has added the ability to use UNIX "shared libraries," eliminating this step. This paper discusses the use of those libraries.

What Is a Shared Library?
When linking a program produced with another language, it is possible to use the linker to produce a library file, containing one or more routines. Traditionally this library has been a "statically linked" library. This means that any program wishing to make use of these routines has needed to include the library within its own executable file. This is achieved through use of a linker utility, which combines the files into a single executable. The process may be viewed diagrammatically in this fashion:

Relinking an executable

One obvious drawback of this technique is that every time any of the routines changes, the whole executable must be relinked. For users of ACUCOBOL-GT, this has only been necessary when non-COBOL routines, or the runtime itself, have changed, but it can still be a tedious and time-consuming process. Relinking also usually requires a C compiler, which may not be readily available on the target platform. Fortunately the UNIX operating system allows us to make use of "shared libraries". With shared libraries, the linker does not include the code for a linked procedure in the runtime, but instead includes a reference to the shared library file that contains the routine's object code. At run time, the system loader loads these libraries and dynamically resolves the references, as they are required.

Shared libraries normally have a prefix of "lib"and a filename extension of ".a" on AIX systems, ".s"' on HP/UX systems, or ".so" on other UNIX and Linux systems. By default, ACUCOBOL GT expects a filename extension of ".so". For other systems, the filename may be symbolically linked to a name ending in ".so", or (from release 5.2.1) the variable SHARED-LIBRARY-EXTENSION may be set to the correct value in the configuration file.

Calling Routines in a Shared Library
The first job is to load the shared library, which is simply done by using the CALL verb:

CALL "sharedlibrary.so".

If no relative or absolute path is specified in the CALL statement, the routine looks for the library in the current working directory. If it is not found, the runtime looks in the location specified by the environment variable LIBPATH on AIX systems, SHLIB_PATH on HP/UX systems, or LD_LIBRARY_PATH on other UNIX and Linux systems.

Once the library is loaded then routines within it may be called in the usual manner:

CALL "sharedroutine" USING WS-PARAM-1, WS-PARAM-2.

In this case the runtime will search for a C subroutine entry point called "sharedroutine" from all shared libraries that have been loaded. If an entry point by this name is not found, the runtime tries to find a COBOL subprogram by that name.

Executable Binary Formats
Most UNIX systems use a binary format that supports calling subroutines in UNIX shared libraries exactly as described in this paper. However, SCO UNIX (and possibly some other UNIX systems) use different binary formats, specfically COFF and ELF. To support calling shared libraries on those systems, the objects and executables must be in the ELF format. You must ensure that any executable you wish to use in such systems (including the ACUCOBOL-GT runtime) is an ELF executable in order to use shared libraries.

####

Acucorp, extend and ACUCOBOL are trademarks or registered trademarks of Acucorp, Inc. All rights reserved. All other trademarks are the property of their respective owners.