XPCOM ABI is the binary interface of XPCOM components. While XPCOM components written in a scripting language (such as JavaScript) can be moved across platforms (such as Windows and OS X) without adaptation, those written in a compiled language (such as C++) require recompilation when moving to a different platform. Often, compiled XPCOM components are called 'binary' or 'native'.
A binary XPCOM component consists of an .xpt file which fits all platforms and a DLL (.dll on Windows, .so on Unix) which is platform-specific and has a certain ABI. Only applications which use this ABI could use this XPCOM component. To put it simply, an XPCOM component built for a specific ABI would only be compatible with Firefox, Thunderbird or other XULRunner application built for the same ABI.
ABI Naming
Each ABI is named with a string [TARGET_XPCOM_ABI] of the following format:
{CPU_ARCH}-{TARGET_COMPILER_ABI}
{CPU_ARCH} [Platforms] represents the CPU architecture and may be either:
x86- i386 and higher series (including x86-64 CPUs in 32-bit mode)ppc- PowerPC seriesAlpha- Alpha seriesx86_64- AMD64/EMT64 series in 64-bit mode (32-bit mode is still consideredx86)sparc- SPARC seriesia64- Itanium series
{TARGET_COMPILER_ABI}[Platforms] represents the compiler ABI and may be either:
msvc- Microsoft Visual C++n32- IRIX 6 C++ Compilergcc2- GNU C++ Compiler 2.xgcc3- GNU C++ Compiler 3.x or 4.xsunc- Sun C++ Compileribmc- IBM C++ Compiler
For example:
- Firefox built with the GNU C++ Compiler 4.0.0 for the Intel Pentium processor would have XPCOM ABI of
x86-gcc3
The XPCOM ABI string can be retrieved programmatically by using the nsIXULRuntime interface. To retrieve the ABI of your Firefox or Thunderbird, open the Error Console (accessible through Tools | Error Console) and evaluate the following JavaScript code:
Components.classes["@mozilla.org/xre/app-info;1"]
.getService(Components.interfaces.nsIXULRuntime)
.XPCOMABI
If either the CPU architecture or the C++ Compiler are unknown, the application wouldn't have an XPCOM ABI string and attempts to get it will result in error NS_ERROR_NOT_AVAILABLE. It would still be a distinct ABI, but we just wouldn't have a name for it.
TARGET_XPCOM_ABI. (This is an internals detail and should be of no concern to an extension developer.)
Extension Installation
When the application (e.g. Firefox) is built, the name of the ABI it supports is embedded into it. Later on, it could use this value to check compatibility with third-party binary XPCOM components.
A common point of compatibility check is during the installation of extensions. If an extension provides binary XPCOM components, it should declare their XPCOM ABI in the Install Manifest. An extension author may build (compile) the XPCOM component for each and every supported machine and pack all the builds into a single XPI, each into its distinctive platform-specific subdirectory. At extension installation time, the application will choose the most fitting component build for its own ABI. If no such build is found, the extension will be deemed incompatible and the application will refuse to install it.
If the application doesn't have an XPCOM ABI string (due to the fact that either its CPU architecture or C++ Compiler are unknown, as described in the ABI Naming section), you should use the operating system's name (without appending the XPCOM ABI) as the platform name in the Install Manifest etc.