Staticness: gpmi, gpmi-static and gpmi-dynamic

1. Introduction

Altough gpmi is mainly dynamic, we want to provide a framework that the developer can use under exotic conditions, such as limited hardware resources, lack of OS features or extreme security needs (more about these later). Thus, gpmi supports static linking of packages (XXX: and later modules).

When we refer to gpmi without a suffix, we mean the version that supports both static and dynamic scheme. Application developer may decide to link some of the libraries static while reserves the possiblity to load others on the fly. This is reasonable for applications depending on packages themselves or depending on modules which depends on those packages.

Another version is gpmi-dynamic, which is dynamic only, lacks all functions to enable static package linking. If you are sure your application won't depend on packages, or you won't want to easily debug it, you may choose to use gpmi-dynamic to save some disk space and memory.

Finally, gpmi-static is the version that has only static package linking. There is no way to load gpmi packages while the application runs.

However, choosing any of the above, you won't note prominent differences in gpmi API. You will need to follow the same steps of loading a library both for static and dynamic schemes, however, in the static case you know that it isn't really loading the package, only registering it. The only one difference is that package loading routines and lowlevel library handling routines have different names in the static version. This means, if you use "gpmi_pkg_load" for loading a dynamic package, you will need to use "gpmi_pkg_load_static" to load the same package in static mode. Calling parameters are exactly the same. At compile time, you need to define (XXX: not implemented yet)

The above applies on gpmi, while gpmi-static has all the dynamic calls bound to static calls (by macros) and gpmi-dynamic binds all static calls to the corresponding dynamic ones.

In a simple case, the application developer developes with the default, dynamic version and use only dynamic calls. XXX: finish this paragraph!

2. Benefits of static linking

Easier debugging. Your debugger will be able to load all the symbols of a static linked package when you start up the program, without running the package initialization part.

Reducing memory usage. On a hardware with very limited resources, especially small memory, it is cheaper to use the static-only version, which tries to be as small as possible, while the dynamic one aims to be as flexible as possible. It may be useful for embedded computing.

Security policy. Allowing an application to import code from the disk is always a security risk, be the code either a script or native. Keeping it in mind that gpmi restricts loading of libraries, an attacker still may gain rights to install his own libraries in one of the library search paths and thus inject his code in an application. This can not happen if all the package the application would ever need is linked in staticly and there are no functions to load dynamic libraries.

On some systems, there are OS limitations so loading dynamic libraries is simply not possible. With gpmi-static, those systems still can run applications modularized with gpmi.