Mozilla Static Build
1. Introduction
- 1.1 What is a "static build"?
- 1.2 What is a "Mozilla static build"?
- 1.3 Why do I want a static build?
2. Mozilla static build variations
- 2.1 Traditional Mozilla static build
- 2.2 Embedding static build
- 2.3 Meta-components static build
- 2.4 Mozcomps meta-component static build
1. Introduction
This document explains the concept of a Mozilla static build.
1.1 What is a "static build"?
Traditionally, a static build refers to the act of linking shared or dynamic libraries directly into the program executable so that the executable has no external dependencies upon those libraries.
1.2 What is a "Mozilla static build"?
In the early days of Mozilla development, Mozilla consisted of
hundreds of shared libraries which represented the individual modules
used by Mozilla. In mid-2000, an effort was
started to allow Mozilla to be built as a static application. Over the
course of this effort, mozilla.org's definition of a static build
diverged from the traditional definition. First, the term "static"
refers to the static linking of Mozilla's internal libraries into the
application executable, not the system libraries. Second, not all of
the internal libraries are statically linked into the executable.
Necessity has dictated that certain
libraries remain dynamic.
1.3 Why do I want a static build?
Traditional static builds provide a number of advantages. First,
you can distribute a static executable without needing to worry about
system library dependencies. Next, by linking the libraries into the
executable, you have eliminated the overhead of shared library calls
which increases the performance of the application. Finally, static
libraries are usually not compiled as position independent code (PIC)
which signficantly decreases the footprint of the library and your
application when you link against the library. The traditional static
build has one primary disadvantage; you will signficantly increase
the footprint of the application overall when you statically link
portions of the system library into it.
The Mozilla static build has many of the same advantages as the
traditional static build, including the reduction of shared library
overhead and footprint. The Mozilla static build also avoids the major
disadvantage of a traditional static build by leaving the system
libraries out of the equation.
2. Mozilla static build variations
There are a number of variations to the Mozilla static builds. Each variation requires that you use the static component loader to register the statically linked components in your application. See http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#1547 and the file generated from http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsStaticComponents.cpp.in .2.1 Traditional Mozilla static build
In the traditional Mozilla static build, all of the internal
libraries are linked into the application executable, with the exception
of the aforementioned forced shared libraries. You can use the standard
configure flags to disable certain modules (ie mailnews) so that they
aren't compiled or linked into the application.
To build the traditional static build, you need to use the following
configure options:
--disable-shared--enable-static
2.2 Embedding static build
With this configuration, you build everything in the tree as you
would for a traditional Mozilla static build but you only link a
pre-defined list of components into your test app. Generally, this list
comes from the embedding
manifest files. This is actually how we link the TestGtkEmbed
application in a traditional Mozilla static build. If you look at http://lxr.mozilla.org/seamonkey/source/embedding/browser/gtk/src/Makefile.in#128
, you'll see some makefile code to work backwards from the traditional
embedding manifest to link only specific libraries into the test
application. You will need to reproduce that makefile code to build your
own embedding applications using this method.
2.3 Meta-components static build
There were some features which span multiple libraries and could be
considered runtime optional. For those features, we created an option
to allow you to merge the individual libraries that compose those groups
of features into a single dynamic library which could be added onto the
static build. Those definitions are stored in http://lxr.mozilla.org/seamonkey/source/config/config.mk#332
. At the time of this writting, we only support the mail & crypto
meta-components.
To build the meta-components static build, you need to use the
following configure options:
--disable-shared--enable-static--enable-meta-components=mail,crypto
2.4 Mozcomps meta-component build
For every shared library that is created by the build system, there
is an approximately 20k of code overhead for that library. We can
reduce the overall footprint of the application as well as speed up the
loading of component shared libraries by combining those component
shared libraries into a single meta-component shared library.
Note: This build variant is
different from the previous static builds in that it does NOT statically link the components
against the application binaries.
To build the mozcomps meta-components static build, you need to use
the following configure options:
--disable-shared--enable-static--enable-meta-components=mozcomps
You can also combine the meta-components options. Any
components placed into the other meta-components will not end up inside
the mozcomps meta-component.