The XPCOM Glue is a static library which component developers and embedders can link against. It allows developers to link only against the frozen XPCOM method symbols and maintain compatibility with multiple versions of XPCOM.
Compiling or linking against XPCOM headers
There are three ways to compile/link against XPCOM headers/libraries:
Frozen linkage: dependent glue (dependent on xpcom.dll)
Code which wishes to use only frozen symbols but can tolerate a load-time dependency on xpcom.dll should link against xpcom.lib and xpcomglue_s.lib. This is the case for XPCOM components.
Frozen linkage: standalone glue (no DLL dependencies)
Embedding code which wishes to use only frozen symbols and cannot tolerate a load-time dependency on <tt>xpcom.dll</tt> should <tt>#define XPCOM_GLUE 1</tt> while compiling, and link against <tt>xpcomglue.lib</tt>. It should not link against <tt>xpcomglue_s.lib</tt> or <tt>xpcom.lib</tt>.
In order to use XPCOM, the embedding application first needs to find where the XPCOM runtime is located. This is typically done using GRE_GetGREPathWithProperties. Then, the code must call XPCOMGlueStartup, which will dynamically link against the XPCOM runtime. Only then can the embedding application initialize and use XPCOM.
This linkage strategy is used when an embedder needs to bootstrap an embedding app by finding a compatible GRE. Extension or XULRunner application components should use the dependent glue.
Embedders using the standalone glue typically also need to avoid linking against NSPR as well.
Emlak ilanlar
Using Mozilla internal linkage
Mozilla internal code defines MOZILLA_INTERNAL_API while compiling and links against xpcom.lib and xpcom_core.lib. In almost all cases embedders should *not* use internal linkage. Components using internal linkage will have shared-library dependencies against non-frozen symbols in the XPCOM libraries, and will not work with any other versions of XPCOM other than the one it was compiled against.
Internal linkage will be unavailable to extension authors in XULRunner 1.9 (Firefox 3) because the nonfrozen symbols will not be exported from libxul. Extension and application authors currently using internal linkage should read the guide on Migrating from Internal Linkage to Frozen Linkage.
Threadsafe nsISupports implementations
When using glue libraries from Gecko 1.8 or later, a special step needs to be taken to use NS_IMPL_THREADSAFE_ISUPPORTS
n
. This is because it forces a dependency on the NSPR library, which can otherwise be avoided. As described in bug 299664, the preprocessor symbol XPCOM_GLUE_USE_NSPR needs to be defined.
Sample Compiler/Linker Flags
Code compiled using XPCOM headers should always <tt>#include "xpcom-config.h"</tt> from the SDK, to ensure that XPCOM #defines are correct.
| Linking Strategy | Compiler Flags | Linker Flags | ||
|---|---|---|---|---|
| Windows | Mac | Linux | ||
| Dependent Glue | <tt style="white-space: pre">#include "xpcom-config.h"</tt> | <tt>-LIBPATH:c:/path/to/sdk/lib xpcomglue_s.lib xpcom.lib nspr4.lib</tt> | <tt>-L/path/to/sdk/lib -L/path/to/sdk/bin -Wl,-executable-path,/path/to/sdk/bin -lxpcomglue_s -lxpcom -lnspr4</tt> | <tt>-L/path/to/sdk/lib -L/path/to/sdk/bin -Wl,-rpath-link,/path/to/sdk/bin -lxpcomglue_s -lxpcom -lnspr4</tt> |
| Standalone Glue | <tt style="white-space: pre">#include "xpcom-config.h" #define XPCOM_GLUE 1</tt> |
<tt>-LIBPATH:c:/path/to/sdk/lib xpcomglue.lib</tt> | <tt>-L/path/to/sdk/lib -lxpcomglue</tt> | <tt>-L/path/to/sdk/lib -lxpcomglue</tt> |
Notes
- Never link against xpcomglue.lib and xpcomglue_s.lib at the same time.
- Never link against xpcomglue.lib and xpcom.lib at the same time.
- These instructions are for Mozilla 1.8 and above. When using a SDK from Mozilla 1.7 or earlier, you must define MOZILLA_STRICT_API when using any form of the glue.