OS/2 Build Prerequisites

  • Revision slug: Developer_Guide/Build_Instructions/OS2_Build_Prerequisites
  • Revision title: OS/2 Build Prerequisites
  • Revision id: 82505
  • Created:
  • Creator: PWeilbacher
  • Is current revision? No
  • Comment /* Required packages */ Oops, the bracket...

Revision Content

This document lists the tools required to build Mozilla products on the OS/2 and eComStation 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 mozilla.dev.ports.os2 on news.mozilla.org.

Warning: While we have succeeded to get the trunk building again on OS/2 with cairo-based rendering (Thebes), it is not quite usable and may break again soon. Bug 371503 tracks progress of this. (You can still build code from trunk checked out using MOZ_CO_DATE 20070206 or earlier, but then use --disable-svg.)

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 sourcecode requires a lot of time and diskspace:

  • Compiling the SeaMonkey suite on an machine with an Athlon XP 3000+ takes between
    • 45min (using GCC 3.2.2, timed SeaMonkey 1.1a on 30Jul2006)
    • 70min (using GCC 3.3.5, timed SeaMonkey 1.1a on 30Jul2006)
    • Depending on compilation options used this may vary by several minutes
  • Firefox and Thunderbird require a few minutes less
  • The source tree on disk takes up to about 350 MiB
  • The binary tree of a release build may use up to 300 MiB
  • If compiling a debug build, more than 1.2 GiB are required

Required packages

The following explains what tools are required to build Warpzilla.

  • In case you are trying to compile on eComStation, you will find most tools for the Mozilla build environment on CD#2 (in \DEVELOP\GCC\, there is an option to install them when running the "Developer's Install Guide"), except the cairo-support package 'mozfntcfgft' below and Python (?).
  • OS/2 Toolkit
    Install the Toolkit that comes with your version of OS/2 or eComStation.
  • EMX runtime
    If not already installed, unzip EMXRT.ZIP in the root directory. It will create a directory called EMX.
    Add D:\EMX\DLL to your LIBPATH in CONFIG.SYS.
  • autoconf
    Unzip AUTOCONF.ZIP in the root directory. It will create a directory called AUTOCONF.
    Note: do not try to use versions newer than 2.13.
  • glibidl
    Unzip the glibidl*.zip file in the root directory. It will create a directory called glibidl.
  • Perl 5.8.0 (bin & core)
    Unzip both zips in the root directory. It will create a directory called PERL.
    In the file PERL\LIB\5.8.0\OS2\CONFIG.PM, find the "archlib" tag (line 120) and change the drive letter to point to where you have installed PERL. (The ReadMe in the package is wrong, you should not use PERL_LIBBATH!)
  • Python (v2.4.4 binaries)
    Unzip zip package into the root directory, it will create a directory called PYTHON244.
  • Support package for cairo-enabled builds mzfntcfgft (careful, do not use Shift click for download!)
    Unzip mzfntcfgft*.zip in the root directory. It will create a directory called mzfntcfgft. In case you are not compiling with GCC 3.3.5 you will need to recompile the package (see the included README.)
    Note: This package is only required for trunk builds. If you want to compile SVG support into a branch build use the older version.
  • There is a package from 2003 which contains most of the required programs listed below: MozTools of 07Aug2003. If you use this package, and have problems, you may have to update CVS and GNU make afterwards.

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.

Compiler

It is no longer possible to compile Mozilla with the IBM VAC++ compiler. Instead, one can choose between the two recent GCC versions that are available on OS/2. It should be possible to build all versions since Mozilla 1.7 with both compilers, but it is recommended to use GCC 3.2.2 for Gecko 1.8.0.x and GCC 3.3.5 for newer versions.

GCC 3.2.2

Download GCC 3.2.2 Beta 4 from the Innotek site and install it. Then download the latest update, GCC 3.2.2 Beta 4 CSD 1, and unpack on top of this installation. Then go into the lib directory and run MakeOmfLibs.cmd. The setup script assumes that you installed into the directory D:\GCC322. If you installed elsewhere, you will have to make the appropriate changes.

If you choose this compiler and want to compile with the SVG/Canvas feature active you have to recompile the mozfntcfgft package after download (by running make in its directory).

GCC 3.3.5

Download the newest version GCC 3.3.5 CSD2 from the Netlabs FTP server, unpack, and go to the lib dir and run MakeOmfLibs.cmd. The setup script 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. Currently, two scripts are available, one for each version of GCC: for GCC 3.2.2 or for GCC 3.3.5. Please adapt any locations listed in this file, in case you did not install on drive D: and in the directory D:\MOZTOOLS. An {{mediawiki.external('https://bugzilla.mozilla.org/attachment.cgi?id=188005 alternative CMD batchfile')}} is attached to {{bug|294088}}, it is adapted for builds with GCC 3.2.2 without SVG/Canvas support, but is structured in a way that should make it easy to edit. 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 client.mk by hand (cvs co mozilla/client.mk) and let the build system pull the rest of the sources (make -f client.mk pull_all). The details of this are described here.

Once you have created the .mozconfig file, you can start the build using
make -f client.mk 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.

Tricks

Some hints that you can try in case of problems. You should also post to the mozilla.dev.ports.os2 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:
    • rm mozilla/configure
    • rm mozilla/nsprpub/configure
    • rm mozilla/directory/c-sdk/configure
    These will be regenerated automatically from the corresponding configure.in 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.
    • It automatically tests many aspects of the build environment, often by generating test programs that it tries to compile with the selected compiler.
    • It leaves a log of its activity in the file config.log (in the OBJDIR is you set one) where you can look up errors.
    • If a critical error occurs, it will print out the sourcecode of the small test program in config.log and leave the respective generated .h files in the same directory. This can be compiled manually and used to track down errors in the build setup.
  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 configure.in files in the tree as well as security\coreconf\OS2.mk 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.

Revision Source

<p>
</p><p>This document lists the tools required to build Mozilla products on the OS/2 and <a class="external" href="http://www.ecomstation.com">eComStation</a> 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 mozilla.dev.ports.os2 on news.mozilla.org.
</p><p><b>Warning</b>: While we have succeeded to get the trunk building again on OS/2 with cairo-based rendering (<i>Thebes</i>), it is not quite usable and may break again soon. <a class="external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=371503">Bug 371503</a> tracks progress of this. (You can still build code from trunk checked out using MOZ_CO_DATE 20070206 or earlier, but then use --disable-svg.)
</p><p>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 <code>D:</code>.
</p>
<h2 name="Hardware_requirements"> Hardware requirements </h2>
<p>Compiling a package as big as the Mozilla sourcecode requires a lot of time and diskspace:
</p>
<ul><li> Compiling the SeaMonkey suite on an machine with an Athlon XP 3000+ takes between
<ul><li> 45min (using GCC 3.2.2, timed SeaMonkey 1.1a on 30Jul2006)
</li><li> 70min (using GCC 3.3.5, timed SeaMonkey 1.1a on 30Jul2006)
</li><li> Depending on compilation options used this may vary by several minutes
</li></ul>
</li><li> Firefox and Thunderbird require a few minutes less
</li><li> The <b>source tree</b> on disk takes up to about <b>350 MiB</b>
</li><li> The <b>binary tree</b> of a release build may use up to <b>300 MiB</b>
</li><li> If compiling a debug build, more than 1.2 GiB are required
</li></ul>
<h2 name="Required_packages"> Required packages </h2>
<p>The following explains what tools are required to build Warpzilla.
</p>
<ul><li> In case you are trying to compile on eComStation, you will find most tools for the Mozilla build environment on CD#2 (in <code>\DEVELOP\GCC\</code>, there is an option to install them when running the "Developer's Install Guide"), except the cairo-support package 'mozfntcfgft' below and Python (?).
</li></ul>
<ul><li> OS/2 Toolkit<br>Install the Toolkit that comes with your version of OS/2 or eComStation.
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/emx/v0.9d/emxrt.zip">EMX runtime</a><br>If not already installed, unzip EMXRT.ZIP in the root directory. It will create a directory called EMX.<br>Add D:\EMX\DLL to your LIBPATH in CONFIG.SYS.
</li><li> <a class="external" href="http://www.axess.com/users/sobotka/warpzilla/srcs/autoconf-gcc.zip">autoconf</a><br>Unzip AUTOCONF.ZIP in the root directory. It will create a directory called AUTOCONF.<br><b>Note</b>: do not try to use versions newer than 2.13.
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/util/glibidl_20070521.zip">glibidl</a><br>Unzip the <code>glibidl*.zip</code> file in the root directory. It will create a directory called <code>glibidl</code>.
</li><li> Perl 5.8.0 (<a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/perl/perl-5.8.0-bin.zip">bin</a> &amp; <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/perl/perl-5.8.0-core.zip">core</a>)<br>Unzip both zips in the root directory.  It will create a directory called PERL.<br>In the file <code>PERL\LIB\5.8.0\OS2\CONFIG.PM</code>, find the "archlib" tag (line 120) and change the drive letter to point to where you have installed PERL. (The ReadMe in the package is wrong, you should <i>not</i> use PERL_LIBBATH!)
</li><li> Python (<a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/python/python-2.4.4-emx-bin-070101.zip">v2.4.4 binaries</a>)<br>Unzip zip package into the root directory, it will create a directory called PYTHON244.
</li><li> Support package for cairo-enabled builds <a class="external" href="http://hobbes.nmsu.edu/cgi-bin/h-search?key=mzfntcfgft_20070528">mzfntcfgft</a> (careful, do not use Shift click for download!)<br>Unzip <code>mzfntcfgft*.zip</code> in the root directory. It will create a directory called <code>mzfntcfgft</code>. In case you are not compiling with GCC 3.3.5 you will need to recompile the package (see the included README.)<br><b>Note</b>: This package is only required for trunk builds. If you want to compile SVG support into a branch build use <a class="external" href="http://hobbes.nmsu.edu/cgi-bin/h-search?key=mozfntcfgft_26aug2006">the older version</a>.
</li></ul>
<ul><li> There is a package from 2003 which contains most of the required programs listed below: <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/util/moztools-03-08-07.wpi">MozTools of 07Aug2003</a>. If you use this package, and have problems, you may have to update CVS and GNU make afterwards.
</li></ul>
<p><b>Note</b>: 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.
</p>
<ul><li> ZIP <a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/archiver/zip23x2.zip">ZIP v2.3 with encryption</a> and UnZIP <a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/archiver/uzs551x2.exe">Unzip v5.51 with unshrink support</a>.<br><b>Note</b>: use this <b>unzip</b> to unpack all packages.
<ul><li> zip.exe
</li><li> unzip.exe
</li></ul>
</li><li> <a class="external" href="http://os2ports.com/ftp/pub/os2/unix/devtools/cvs/cvs11204.zip">CVS</a>
<ul><li> cvs.exe
</li></ul>
</li><li> <a class="external" href="ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/source/os2tools.zip">NSINSTALL</a>
<ul><li> nsinstall.exe
</li></ul>
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/shell/ashos2.zip">BSD Ash</a>
<ul><li> ash.exe
</li></ul>
</li><li> GNU shell utilities (<a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/shell/gnusutil.zip">gnusutil.zip v1.12</a>)
<ul><li> Unzip and copy EXE\*.EXE and EXE\*.DLL to your MOZTOOLS dir.
</li></ul>
</li><li> GNU bash <a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/shell/bash-2.0-b264.zip">bash v2.0-b264</a>
<ul><li> bash.exe
</li></ul>
</li><li> GNU text utilities (<a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/file/gnututil.zip">gnututil v1.19</a>)
<ul><li> Unzip and copy EXE\*.EXE and EXE\*.DLL to your MOZTOOLS dir.
</li></ul>
</li><li> GNU file utilities (<a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/file/gnufutil.zip">gnufutil.zip v3.13</a>)
<ul><li> Unzip and copy EXE\*.EXE and EXE\*.DLL to your MOZTOOLS dir.
</li></ul>
</li><li> GNU diff (<a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/file/diffutils-2.8.zip">diffutils v2.8</a>)
<ul><li> Unzip OS2TREE.ZIP
</li><li> Copy everything from USR\BIN to your MOZTOOLS dir.
</li></ul>
</li><li> GNU grep (<a class="external" href="http://unixos2.com/pub/binary/grep/grep-2_5_1-bin.zip">grep v2.5.1</a>)
<ul><li> Copy everything in BIN to your MOZTOOLS dir.
</li></ul>
</li><li> GNU awk (<a class="external" href="http://unixos2.com/pub/binary/gawk/gawk-3_1_2-bin.zip">gawk v3.1.2</a>)
<ul><li> Copy USR\BIN\GAWK.EXE to your MOZTOOLS dir.
</li><li> Copy gawk.exe to awk.exe
</li></ul>
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/misc/gnum4.zip">GNU m4 v1.4</a>
<ul><li> m4.exe
</li></ul>
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/util/make-3.81-r2-bin.zip">GNU make 3.81</a>
<ul><li> make.exe
</li></ul>
</li><li> <a class="external" href="http://unixos2.com/pub/binary/gettext/gettext-0_11_5-r2-bin.zip">gettext-0_11_5-r2-bin.zip</a>
<ul><li> intl.dll
</li></ul>
</li><li> GNU <a class="external" href="http://unixos2.com/pub/binary/sed/sed-4_0_5-bin.zip">sed v4.0.5</a>
<ul><li> sed.exe
</li></ul>
</li><li> GNU <a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/disk/gnufind.zip">find v4.1</a>
<ul><li> find.exe
</li><li> xargs.exe
</li><li> gnufind.dll
</li><li> gnuregex.dll
</li><li> Copy gnuregex.dll to regex.dll (the latter is needed by grep.exe)
</li></ul>
</li><li> <a class="external" href="ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip">RC.EXE</a><br><b>Note</b>: the linked package contains rc.exe v.5.00.004 but one really needs v.5.00.007 to compile the sources without changes! That version is included in the eCS moztools package, but if you cannot get hold of it, you have to apply the patch from {{template.Bug(272194)}}, i.e. <a class="external" href="https://bugzilla.mozilla.org/attachment.cgi?id=180581">attachment 180581</a>
</li><li> <a class="external" href="ftp://ftp.software.ibm.com/ps/products/warpzilla/ilink50.zip">ILINK 5.0</a>
<ul><li> Copy everything in BIN to your MOZTOOLS dir.
</li></ul>
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/dev/util/gnupatch.zip">GNU Patch v2.5</a>
<ul><li> patch.exe
</li></ul>
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/util/archiver/gtar258.zip">GNU Tar v1.10</a>
<ul><li> tar.exe
</li></ul>
</li><li> <a class="external" href="http://hobbes.nmsu.edu/pub/os2/apps/graphics/convert/winico92-2.zip">Icon converter version 0.92-2</a>
<ul><li> winico.exe
</li></ul>
</li></ul>
<h2 name="Compiler"> Compiler </h2>
<p>It is no longer possible to compile Mozilla with the IBM VAC++ compiler. Instead, one can choose between the two recent GCC versions that are available on OS/2. It should be possible to build all versions since Mozilla 1.7 with both compilers, but it is recommended to use GCC 3.2.2 for Gecko 1.8.0.x and GCC 3.3.5 for newer versions.
</p>
<h3 name="GCC_3.2.2"> GCC 3.2.2 </h3>
<p>Download <a class="external" href="http://download.innotek.de/gccos2/3.2.2-Beta4/gcc-3.2.2-beta4.exe">GCC 3.2.2 Beta 4</a> from the Innotek site and install it. Then download the latest update, <a class="external" href="http://download.innotek.de/gccos2/3.2.2-Beta4/gcc-3.2.2-beta4csd1.zip">GCC 3.2.2 Beta 4 CSD 1</a>, and unpack on top of this installation. Then go into the <b>lib</b> directory and run <b>MakeOmfLibs.cmd</b>. The setup script assumes that you installed into the directory <b>D:\GCC322</b>. If you installed elsewhere, you will have to make the appropriate changes.
</p><p>If you choose this compiler and want to compile with the SVG/Canvas feature active you have to recompile the <b>mozfntcfgft</b> package after download (by running <b>make</b> in its directory).
</p>
<h3 name="GCC_3.3.5"> GCC 3.3.5 </h3>
<p>Download the newest version <a class="external" href="ftp://ftp.netlabs.org/incoming/gcc/GCC-3.3.5-csd2.zip">GCC 3.3.5 CSD2</a> from the Netlabs FTP server, unpack, and go to the <b>lib</b> dir and run <b>MakeOmfLibs.cmd</b>. The setup script assumes that you installed into the directory <b>D:\GCC335</b>. If you installed elsewhere, you will have to make the appropriate changes.
</p>
<h2 name="Build_environment"> Build environment </h2>
<p>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 <b>moztools</b> dir.
</p><p>This environment is set up using REXX scripts <b>setmozenv*.cmd</b>. Currently, two scripts are available, one for each version of GCC: for <a class="external" href="http://pmw-warpzilla.sf.net/setmozenv_gcc322.cmd">GCC 3.2.2</a> or for <a class="external" href="http://pmw-warpzilla.sf.net/setmozenv_gcc335.cmd">GCC 3.3.5</a>. Please adapt any locations listed in this file, in case you did not install on drive <b>D:</b> and in the directory <b>D:\MOZTOOLS</b>.
<span class="comment">An {{mediawiki.external('https://bugzilla.mozilla.org/attachment.cgi?id=188005 alternative CMD batchfile')}} is attached to {{bug|294088}}, it is adapted for builds with GCC 3.2.2 without SVG/Canvas support, but is structured in a way that should make it easy to edit.</span>
To set the environment, open a CMD shell and start the batch file.
</p>
<h2 name="Getting_sources_and_building"> Getting sources and building </h2>
<p>The <a href="en/Configuring_Build_Options">options for the build</a> are taken from <code>.mozconfig</code> which is a file you create in the <code>mozilla</code> directory. They can also be generated using the <a class="external" href="http://webtools.mozilla.org/build/config.cgi">Unix Build Configurator</a> but you should start with a minimal file first, like this one:
</p>
<pre>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</pre>
<p>that would create an optimized SeaMonkey build, with binaries located in the directory <code>obj</code> under the <code>mozilla</code> directory.
</p><p>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 <code>client.mk</code> by hand (<code>cvs co mozilla/client.mk</code>) and let the build system pull the rest of the sources (<code>make -f client.mk pull_all</code>). The details of this are described <a href="en/Mozilla_Source_Code_Via_CVS#Selecting_a_Project_to_Pull">here</a>.
</p><p>Once you have created the <code>.mozconfig</code> file, you can start the build using<br>
<code>make -f client.mk build 2&gt;&amp;1 | tee build.log</code><br>
(The redirection and <code>tee</code> call keeps a logfile of the whole build in the file <code>build.log</code> but also issues all the messages to the screen.)
</p><p>Once the build is complete, the binaries can be found in <code>obj/dist/bin</code>. If you want to make a package, please follow the instructions on <a href="en/Building_a_SeaMonkey_package">Building a SeaMonkey package</a>.
</p><p>If these information is not enough, there is some background info in <a href="en/How_Mozilla's_build_system_works">How Mozilla's build system works</a>.
</p>
<h2 name="Tricks"> Tricks </h2>
<p>Some hints that you can try in case of problems. You should also post to the mozilla.dev.ports.os2 newsgroup if you have problems.
</p>
<ol>
<li>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:
<ul>
<li><code>rm mozilla/configure</code>
</li><li><code>rm mozilla/nsprpub/configure</code>
</li><li><code>rm mozilla/directory/c-sdk/configure</code>
</li></ul>
These will be regenerated automatically from the corresponding configure.in file when you kick off the build in the next step. To generate them manually, go to each directory and run 'bash autoconf'.</li>
<li>The first step of the build process uses the <b>configure</b> script generated by <a class="external" href="http://www.gnu.org/software/autoconf/">GNU autoconf</a>.
<ul>
<li>It automatically tests many aspects of the build environment, often by generating test programs that it tries to compile with the selected compiler.
</li><li>It leaves a log of its activity in the file <b>config.log</b> (in the <b>OBJDIR</b> is you set one) where you can look up errors.
</li><li>If a critical error occurs, it will print out the sourcecode of the small test program in config.log and leave the respective generated .h files in the same directory. This can be compiled manually and used to track down errors in the build setup.</li>
</ul>
</li><li>If you are building the Mozilla code to be able to compile an extension for use with OS/2 (e.g. <a class="external" href="http://enigmail.mozdev.org/">enigmail</a>) then it is a good idea to edit all three <code>configure.in</code> files in the tree as well as <code>security\coreconf\OS2.mk</code> and replace <code>emxexp -o</code> with just <code>emxexp</code> in the definition of the <code>FILTER</code> 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.</li>
</ol>
Revert to this revision