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.
There are three ways to compile/link against XPCOM headers/libraries:
XPCOM modules, i.e. extension or XULRunner application components, should use the dependent glue.
Code which wishes to use only frozen symbols but can tolerate a load-time dependency on xpcom.dll should link against xpcomglue_s.lib and xpcom.lib. It should not link against xpcom_core.lib. This is the case for XPCOM components, because they are loaded into Mozilla which already has full XPCOM loaded and initialized.
Note: Support for locating a standalone glue was removed in Gecko 6.0.
Use this when you have a custom application where you want to embed Gecko to show webpages in your own window. I.e. this linkage strategy is used when an embedder needs to bootstrap XPCOM by finding a compatible GRE on disk and loading it.
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.
Embedding code which wishes to use only frozen symbols and cannot tolerate a load-time dependency on xpcom.dll should #define XPCOM_GLUE 1 while compiling, and link against xpcomglue.lib. It should not link against xpcomglue_s.lib or xpcom.lib.
Embedders using the standalone glue typically also need to avoid linking against NSPR as well. However, when using threadsafe together with the glue libraries from Gecko 1.8 or later, a special step needs to be taken to use NS_IMPL_THREADSAFE_ISUPPORTSn. 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.
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.
Code compiled using XPCOM headers should always #include "xpcom-config.h" from the SDK, to ensure that XPCOM #defines are correct.
| Linking Strategy: | Dependent Glue | Standalone Glue |
|---|---|---|
| Compiler Flags: | ||
| Cross-Platform | #include "xpcom-config.h" |
#include "xpcom-config.h" |
| Windows | /FI "xpcom-config.h" |
|
| Linux | -include "xpcom-config.h" |
|
| Linker Flags: | ||
| Windows |
For older versions of the Firefox SDK:
For recent versions of the Firefox SDK (at least version 42, but possibly earlier versions as well):
|
-LIBPATH:c:/path/to/sdk/lib xpcomglue.lib |
| Mac |
when building against a XulRunner derived SDK, use: |
-L/path/to/sdk/lib -lxpcomglue |
| Linux |
Write it exactly as stated, see Notes. |
-L/path/to/sdk/lib -lxpcomglue |
.pc files. For example: pkg-config --cflags --libs libxul.pcundefined symbol: ...NS_TableDrivenQI...QITableEntry... at runtime (not compile time) (in debug builds) or your module just won't load (in optimized builds).#include "mozilla-config.h" should also work, if it's the first #include in .cpp, but preprocessor option is how it's usually included.