|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
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.
The approach used by other platforms, where plugin modules are linked directly against any static libraries which they require, has several advantages.
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.
|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]|
This document was generated using texi2html 1.76.