当前位置：文江博客知识库 en-US 文档 Mozilla Tech XPCOM Glue

XPCOM glue 编辑

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)

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.

Frozen linkage: standalone glue (no DLL dependencies)

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.

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.

Sample Compiler/Linker Flags

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" #define XPCOM_GLUE`
Windows	`/FI "xpcom-config.h"`
Linux	`-include "xpcom-config.h"`
Linker Flags:
Windows	For older versions of the Firefox SDK: `-LIBPATH:c:/path/to/sdk/lib xpcomglue_s.lib xpcom.lib nspr4.lib` For recent versions of the Firefox SDK (at least version 42, but possibly earlier versions as well): `-LIBPATH:c/path/to/sdk/lib xpcomglue_s.lib xul.lib nss3.lib mozcrt.lib`	-LIBPATH:`c:/path/to/sdk/lib` xpcomglue.lib
Mac	`-L/path/to/sdk/lib -L/path/to/sdk/bin -Wl,-executable-path,/path/to/sdk/bin -lxpcomglue_s -lxpcom -lnspr4` when building against a XulRunner derived SDK, use: `-L/path/to/sdk/lib -L/path/to/xulrunner-bin -Wl,-executable_path,/path/to/xulrunner-bin -lxpcomglue_s -lxpcom -lnspr4` where 'xulrunner-bin' is either `/Library/Frameworks/XUL.framework/Versions/Current/` or `/path/to/xulrunner-build/[platform]/dist/bin`	`-L/path/to/sdk/lib -lxpcomglue`
Linux	`-L/path/to/sdk/lib -L/path/to/sdk/bin -Wl,-rpath-link,/path/to/sdk/bin -lxpcomglue_s -lxpcom -lnspr4` Write it exactly as stated, see Notes.	`-L/path/to/sdk/lib -lxpcomglue`

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.
For XULRunner 1.9, on Linux you should use either the .pc files. For example: pkg-config --cflags --libs libxul.pc
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.
Linux and Mac: Make sure the Gecko libraries are listed after your object (.o) files on the link line.
Linux and Mac: Write the linker options exactly as stated (just replacing the /path/to/sdk/), otherwise you get an undefined symbol: ...NS_TableDrivenQI...QITableEntry... at runtime (not compile time) (in debug builds) or your module just won't load (in optimized builds).
In principle, #include "mozilla-config.h" should also work, if it's the first #include in .cpp, but preprocessor option is how it's usually included.
For XULRunner 2.0, you also need to link against mozalloc. This is not a backwards-compatible change with 1.9.x and earlier. On Linux and Mac, add "-lmozalloc" exactly after "-lnspr4" in your linker invocation. On Windows, add "mozalloc.lib" after "nspr4.lib". Please see XPCOM Glue without mozalloc to learn how to create XPCOM components that aren't dependant on mozalloc, and thus are compatible with versions of XULRunner prior to 2.0.
To link against XPCOM using recent versions of the Firefox SDK (at least version 42, but possibly earlier versions as well), you need to link against xul (libxul/xul.lib).
To link against NSPR using recent versions of the Firefox SDK (at least version 42, but possibly earlier versions as well), you need to link against NSS, libnss3/nss3.lib in particular. This is because NSPR is now merged into NSS during the build process.
To link against libxpcomglue_s/xpcomglue_s.lib using recent versions of the Firefox SDK (at least version 42, but possibly earlier versions as well), you also need to link against libmozcrt/mozcrt.lib.