Introduction

Wherever possible, the LayGO API is provided in the form of sharable object files: dynamically linked libraries (DLLs) for Win32 and shared objects for Solaris and Linux. Client programs generally access the exported functions from these files by statically linking to the appropriate export library when the program is built.

The advantages of static or build-time linking are:

• The compiler can perform strict type-checking of function arguments and return values at compile-time.
• The linker can resolve all symbol references to items in the shared objects at build-time.
• The operating system's runtime loader will automatically locate and load the required shared object files when it executes the program. (This is often referred to as implicit loading).

• All the shared objects which might be referred to by a program must be present at runtime, even if the program never actually refers to them.
• The program cannot choose between different implementations of the same shared object at runtime.

Most operating systems which support shared objects also support an alternative to implicit loading with build-time symbol resolution. Sometimes called explicit loading, this alternative allows loading of shared objects under program control, with the program performing its own explicit symbol resolution at runtime. This is usually known (somewhat confusingly) as dynamic loading since the decision about which shared objects to load is made "dynamically" at runtime instead of "statically" at link-time. Dynamic loading is accomplished through the LoadLibrary() API in Win32 and the dlopen() API in Unix.

The option of dynamically loading LayGO shared objects has always been available to LayGO client programs on a do-it-yourself basis. Now the LayGO Toolkit supports a portable, type-safe dynamic loading option through a new set of API functions. This manual explains how to write and build programs using the LayGO Dynamic Loading API.