Loading Shared Libraries with the CALL Statement

You can load a shared object library programatically with the CALL statement. Once the shared library is loaded, you can call any function exported by the library with a CALL statement. For syntax and rules, see CALL Statement. For example, the following statement loads "sharedlibrary.so":

CALL "sharedlibrary.so"

Filename Extensions

The default filename extension of shared libraries is ".so". You can specify a different extension in the CALL statement, or the default extension can be redefined with the SHARED_LIBRARY_EXTENSION runtime configuration variable. See SHARED_LIBRARY_EXTENSION.

You can also NOT specify a file extenstion in which case the runtime will search for the file. The runtime will prepend various prefixes and append various suffixes to the name given, searching sequentially through the list of names until a name is found that can be loaded.

On UNIX, the runtime will first try the name as given and then prepend in order "lib" or "cob". It will also append in order ".so", ".sl", ".a".

On 64-bit UNIX machines, the runtime will also append the following suffixes in order: "64", "64.so", "64.sl", "64.a".

For example, when trying to load "aclnt" on UNIX, the runtime attempts to load the following library names, stopping when one is found:





aclnt64 (64-bit only)

aclnt64.so (64-bit only)

aclnt64.sl (64-bit only)

aclnt64.a (64-bit only)





libaclnt64 (64-bit only)

libaclnt64.so (64-bit only)

libaclnt64.sl (64-bit only)

libaclnt64.a (64-bit only)





cobaclnt64 (64-bit only)

cobaclnt64.so (64-bit only)

cobaclnt64.sl (64-bit only)

cobaclnt64.a (64-bit only)

File Locations

If no relative or absolute path is specified, the runtime looks for the library in the current working directory, the locations specified in the operating system's environment variable for shared libraries; for example, LIBPATH, LD_LIBRARY_PATH, or SHLIB_PATH), and then in the locations specified in the SHARED_LIBRARY_PREFIX configuration variable. See Configuration Variables for more information.

Like other programs that are loaded with a CALL statement, you can unload a CALLed shared library with a CANCEL statement. When you CANCEL a shared library, you may no longer call its exported functions. Unless the logical cancels feature is enabled, all memory used by the program is released. For information about runtime memory management and the logical cancels feature, see Memory Management.

Note: While most UNIX systems use a binary format that supports calling subroutines in shared libraries exactly as described in this section, SCO UNIX (and possibly some other UNIX systems) uses different binary formats, namely COFF and ELF. On those systems, in order to support calling shared libraries, the objects and executables must be in the ELF format. See the UNIX "man" page for your C compiler on how to create ELF format objects (on some systems, for example, you specify the "-b elf" C compiler option).