Note: This page is about building Mozilla applications on OS/2 as checked out from CVS. Building from Mercurial is possible, but only rudimentary documentation exist in Building on OS/2 using Mercurial.

This document lists the tools required to build Mozilla products on the OS/2 platform and gives directions how to configure, download, and start a build. We have tried to be as detailed as possible with these instructions. In case you find errors or have problems, please ask for help in the newsgroup on

This document is designed for someone creating a build environment from scratch. The build environment is easiest to set up when all the tools are placed on a single drive. For our examples, we will use D:.

Hardware requirements

Compiling a package as big as the Mozilla source code requires a lot of time and disk space:

Required packages

The following explains what tools are required to build Warpzilla.

Note: For the following packages, you only need to extract the files we specify from the ZIPs. We recommend putting all of the following EXEs and DLLs in one directory called MOZTOOLS.


You should use GCC 3.3.5 for building any Mozilla application. It is no longer possible to compile Mozilla with the IBM C/C++ compiler, and while GCC 3.2.2 still works for branch builds, it does not work with the trunk any more without additional workarounds (since approximately September 2007).

Download the newest version GCC 3.3.5 CSD3 from the Netlabs FTP server, unpack, and go to the lib dir and run MakeOmfLibs.cmd. The setmozenv script (attached to this page) assumes that you installed into the directory D:\GCC335. If you installed elsewhere, you will have to make the appropriate changes.

Build environment

The build process expects all packages listed above to be installed. They are found either through specific environment variables (e.g. for Perl and AutoConf) or through PATH/LIBPATH that includes the moztools dir.

This environment is set up using REXX scripts setmozenv*.cmd. Use the script for GCC 3.3.5 as attached to this page.  Please adapt any locations listed in this file, in case you did not install on drive D: and in the directory D:\MOZTOOLS. To set the environment, open a CMD shell and start the batch file.

Getting sources and building

The options for the build are taken from .mozconfig which is a file you create in the mozilla directory. They can also be generated using the Unix Build Configurator but you should start with a minimal file first, like this one:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj
mk_add_options MOZ_CO_PROJECT=suite

ac_add_options --enable-application=suite
ac_add_options --disable-tests
ac_add_options --enable-optimize
ac_add_options --disable-debug

that would create an optimized SeaMonkey build, with binaries located in the directory obj under the mozilla directory.

The source code of Mozilla is distributed via CVS, the setmozenv script already sets up the environment for that. In principle you need to select a project to pull from CVS (add a line MOZ_CO_PROJECT to your .mozconfig), check out the main makefile by hand (cvs co mozilla/ and let the build system pull the rest of the sources (make -f pull_all). The details of this are described here.

Once you have created the .mozconfig file, you can start the build using
make -f build 2>&1 | tee build.log
(The redirection and tee call keeps a logfile of the whole build in the file build.log but also issues all the messages to the screen.)

Once the build is complete, the binaries can be found in obj/dist/bin. If you want to make a package, please follow the instructions on Building a SeaMonkey package.

If these information is not enough, there is some background info in How Mozilla's build system works.


Some hints that you can try in case of problems. You should also post to the newsgroup if you have problems.

  1. Although the command to pull the sources from CVS should do this automatically, it is sometimes necessary to delete the three configure files so that they can be properly generated on OS/2. This usually happens when there is a CVS conflict when pulling the code. If you encounter errors during the build, you should try deleting the configure files: These will be regenerated automatically from the corresponding file when you kick off the build in the next step. To generate them manually, go to each directory and run 'bash autoconf'.
  2. The first step of the build process uses the configure script generated by GNU autoconf.
  3. If you are building the Mozilla code to be able to compile an extension for use with OS/2 (e.g. enigmail) then it is a good idea to edit all three files in the tree as well as security\coreconf\ and replace emxexp -o with just emxexp in the definition of the FILTER variable. Then remove all configure files as described in trick 1. If you do that then the extension will be longer lived and does not have to be rebuilt with every new version.
  4. If you are normally using the 4OS2 shell instead of plain CMD, you should set COMSPEC to CMD.EXE again in your build environment in case you encounter problems.
  5. If you are building on a system that has an X11 development environment and you get linker errors, you might want to try to build with ac_add_options --without-x in your .mozconfig.