You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Building A Mozilla Distribution

These are directions for creating your own milestone build or any other distribution. You might want to create your own distribution in order to create a build for some platform that's not normally on our ftp site or to enable some feature that's not supported in the standard builds.

  1. Download the special milestone source tarball and build from it, not from your normal tree. If the tarball isn't out yet, the README file in the milestone directory contains instructions for pulling the correct source via CVS. Remember to pull from the correct tag. For example,
    cvs co -r MOZILLA_1_0_2_RELEASE mozilla/
    cd mozilla
    gmake -f checkout
  2. Set the build options to disable debugging symbols, create optimized code, set the build date (which is used in bugzilla) plus whichever other options you choose.
  3. Test your build to make sure it runs and make a note of the BuildID number in the lower right hand corner of the app. It should look something like 2001102513 and reflect the date and time you built the package.
  4. Create a README file which contains as much of the following as possible.
    • Your contact information, including your bugzilla id so if someone reports a problem specific to your package, the bug can be assigned to you.
    • BuildID
    • Library dependencies.
    • The options you used to create the build.
    • Anything non-standard that you enabled (or disabled) in the build including patches or links to patches that you applied.
  5. Make the tarball available somewhere and let us know so we can move it to the ftp site. Its would be nice to also create an md5 checksum file for the tarball and even nicer if you could digitally sign the md5sum file.
    md5sum mozilla-i686-pc-linux-gnu-0.9.5.tar.gz 
    > mozilla-i686-pc-linux-gnu-0.9.5.tar.gz.md5sum

Creating a distribution

It helps to be familiar with the build instructions and with using the unix build configurator to create a mozconfig file.

  1. Download the source.
    Download a source tarball of the latest milestone. or follow the instructions in the current milestone's README file to pull by tag from CVS. (If you're making a distribution from code in your own private tree you'll probably need to gmake -f distclean first).
  2. Configure the build environment.
    Create a file in the tree created from your tarball called mozilla/.mozconfig. You'll want to add these options to make your distribution smaller. The --disable-debug option is pretty important otherwise your package will be 50mb or more. Normal packages are around 10MB. The --enable-optimize option enables the compiler option to build optimized binaries. Feel free to turn on other options such as SVG which aren't enabled in the official builds.

    If you are building binaries that will be distributed to a wide variety of systems, or which do not have all the same shared libraries to link against at runtime, building mozilla's zlib and jpeg libraries for distribution is a good idea.

    ac_add_options --disable-tests
    ac_add_options --disable-debug
    ac_add_options --enable-optimize
    ac_add_options --without-system-nspr
    ac_add_options --without-system-zlib
    ac_add_options --without-system-jpeg
    ac_add_options --without-system-png
    ac_add_options --without-system-mng
    ac_add_options --enable-crypto #comment to disable PSM/SSL support

    Set these environment variables so the build date will be set correctly.

    Unix/Mac OS X:



  3. Build the tree.
    Make sure not to use your regular build command to compile a milestone build since you don't want to do a cvs update. If you sync the tree, you'll be building from the tip and no longer have a milestone build.
    gmake -f build
  4. Add The README.

    Copy your README file to mozilla/dist/bin so it will be included in the tarball created in the next step. For unix variants with ldd, use the following command to create the list of dependencies for unix builds:

    ldd mozilla-bin components/*.so | awk '{ if (/=/ && !/not found/ ) print $3 }' | sort | uniq
    If using tcsh, you may need to escape the ! .
  5. Create the package.
    • To create a tarball (or zip or dmg):

      There is a make file in the packager directory that will create a tarball for you in a package directory. It should place your package in mozilla/dist.

      For os/2 & win32 builds, the default package type is zip.
      For Mac OS X, the default package type is dmg.
      For all other builds, the default type is tar.gz.

      gmake -C mozilla/xpinstall/packager
    • To create a unix installer:

      To build the unix installer, change to the xpinstall builder directory and run the perl script. This creates the file mozilla-$platform$-installer.exe in mozilla/installer.

      cd mozilla/xpinstall/packager/unix/
      perl <version> <urlpath> <stubname> <blobname>
    • To create a win32 installer, you need the following:
      • ActiveState or cygwin Perl
      • Msvcrt.dll and msvcirt.dll These files must be copied to the %MOZ_SRC%\redist\microsoft\system directory on your build system. Without these files, the build will not fail, but the package you create will have problems on rare Windows systems that don't already have the files installed (mostly Win95) as described in bug 27601. The system files can be found at:

      To build the win32 installer, change to the xpinstall builder directory and run the perl script. This creates the file mozilla-win32-installer.exe in mozilla\dist\install.

      cd mozilla\xpinstall\wizard\windows\builder
  6. Test.
    Test your package to make sure it works. Our smoke tests are designed for this purpose.
  7. Distribute.
    Make the tarball available somewhere and let us know so we can move it to the ftp site. Let us know the BuildID as well as anything useful about your build environment such as the version of the OS, the name of the distribution, optional components you included, or whether you're using a non-standard compiler.

    Every package should include a README file.

Contact: Dawn Endico