6.1.1.3 Dynamic Linking

On most platforms, symbols are private to a plugin module unless explicitly exported. However, on MacOS/X, symbols in plugin modules are typically public by default. Prior to MacOS/X 10.1, symbols in plugins existed in a flat namespace shared by the application and all plugin modules. This means that it was possible for symbols defined in one plugin to conflict with those defined in the application or in other plugins. As of MacOS/X 10.1, Apple introduced the concept of two-level namespace, in which symbols for a plugin exist within that plugin's own namespace, thus eliminating the problem of symbolic conflicts between plugins and the application, or plugins and other plugins.

On other platforms, where plugin symbols are private by default, plugin modules are themselves link against any required static libraries in order to satisfy external symbolic references. Historically, this differed from pre-10.1 MacOS/X in which it was customary to link the application against any libraries which might have been required by plugin modules, rather than linking the plugin modules, themselves, against the libraries. There are a couple problems with this older approach.

• It is not always possible to know ahead of time which static libraries will be required by a set of plugin modules since those modules may come from independent sources. Thus, it is neither practical nor always possible to link the application against the correct set of static libraries. As a corollary, this often means having to add special cases to otherwise general makefiles in order to specify an extended set of static libraries when invoking the static linker to build the application's executable image.
• Even though an application may be linked against a static library for the purpose of making that library available to a plugin module, often the application itself makes no reference to symbols within the library. In order to force the linker to actually incorporate the library into the application some artificial mechanism for forcing references to symbols within the library must be invented. Often this involves employing special switches when invoking the linker or manually faking hard symbolic references within the source code itself.
• It is highly fragile and often problematic since even a small change to the external symbolic references of a plugin module may require that the application be relinked against a different set of static libraries.

The approach used by other platforms, where plugin modules are linked directly against any static libraries which they require, has several advantages.

• Plugin modules are self-contained since external symbolic references have already been satisfied, thus there is no need for the application to attempt to satisfy those references.
• An application needs to be linked only against the set of libraries which it requires. There is no need to try to fathom the set of libraries which might one day be required by plugin modules. As a corollary there is no need to invent artificial mechanisms for forcing libraries to be linked into the application which are not required by the application itself.
• It is much more robust since a change in the symbolic requirements of any given plugin module will not require re-linking of the application against a new set of libraries.

Prior to the introduction of two-level namespaces with MacOS/X 10.1, in order to avoid the fragility of flat namespaces, and in order to avoid having to invent special case solutions to work around these problems, the MacOS/X port of Crystal Space emulated the model of dynamic linking used on other platforms. This was accomplished by linking plugin modules against the static libraries which they require, rather than linking those libraries into the application.

The one major pitfall which makes employment of this approach difficult in a flat namespace, is that of symbolic conflicts where the same symbol is defined in more than one place. This problem can occur, for instance, when more than one plugin module links with the same static library, and when both a plugin module and the application link against the same static library. To work around this problem, the MacOS/X port takes advantage of DYLD's ‘NSLinkEditErrorHandlers’ which allows the loader to ignore duplicate symbols at load time.

Although this special manual symbol management is not required with two-level namespaces, the functionality is nevertheless retained for backward compatibility with older MacOS/X releases.

This document was generated using texi2html 1.76.