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.

GeckOS/2 Build Instructions

This document explains how to build Warpzilla Gecko (the OS/2 port of the new Mozilla NGLayout browser) with autoconf and the emx+gcc development kit. The build using VisualAge C++ (vacpp) is presently broken but in the process of being autoconfed and revived.

WHAT'S NEW (1998/12/12):

  • The long list of manual tweaks and gawky workarounds for build breaks is history, and the build itself is now a simple, three-step process (the Lizard Waltz):
    1. autoconf
    2. configure
    3. gmake
  • GNU make 3.76.1 is now required instead of version 3.75.

  • You have the option of using prebuilt versions of the standard jpeg, zlib and png libraries.

Getting Ready

System requirements:
    • Pentium with at least a 133 MHz processor
    • About 125 megs of HPFS-formatted hard drive space (50MB for the sources and 75MB for compiler output, less with debugging turned off).
    • Minimum 64 megs of RAM

Downloading and installing the tools is probably the most painstaking part of the build process. Yet chances are you already have some or all of them on your system. If so, make sure you have the specified versions.

    • GNU emx+gcc v0.9c development kit. Be sure to get which has the socket support (essential) as well as the latest patch. This must be installed on an HPFS drive, as long header file names are assumed. Once you've installed the package, expand the header names to their full filenames:
    • cd emx\include
      Also, make .lib libraries from the .a libraries that come with emx:
      cd emx\lib
    • pgcc development kit v1.0.2. Note we do not currently support pgcc for the build process; this support is on its way. You will specifically need to install and the directory from from this library. Be sure to place the directory in your LIBPATH, or copy the two files in that directory to \emx\dll.
    • GNU bash 2.00.0(266) shell which you should rename gbash.exe, because that's what the build process expects.
    • GNU make 3.76.1. Using version 3.75 produces garbage instead of a slash in /js and /libpref. Meanwhile the bug that kept us from using 3.76.1, namely the deletion of config/ and, has been found and fixed. The instructions below assume GNU make has been renamed gmake.exe.
    • GNU sed v3.00
    • GNU file, shell and text utilities.
    • Perl from Hobbes or the latest version
    • GNU awk v3.0.3, which you should rename to awk.exe (again, expected by the build).
    • GNU autoconf v2.12 patchlevel 5
    • . Install instructions are available at the former maintainer's site.
    • GNU m4 v1.4 (required for autoconf)
    • CVS v1.10. You'll want this for grabbing the latest source.
    • (Optional) Patched version of emxomf.exe which turns off some warnings. Not strictly needed, but useful if you are looking for a cleaner build TODAY. (Don't worry, the warnings will eventually be fixed.)

Getting Set

  1. Download and carefully install all of the above tools that you don't already have on your system. If you already have a tool, be sure you have the latest version of that tool. Make sure they're all in your path and, while you're there, add [x:\...]\warpzilla\config\OS24.0_EMX_DBG.OBJ to it so that the build process can find nsinstall.exe immediately after building it. A cool way to avoid dumping everything into emx/bin and have a shorter PATH statement is TVFS in case you haven't already discovered this little gem of a utility.

  3. Install the NGLayout source. You have two options:
    2. CVS. Get the latest source from the developers' OS/2 CVS server:

    3. set
      cvs login. Use anonymous as your password.
      cvs -z[X] co warpzilla to pull the code.

       The optional -z[X] runs gzip compression which speeds things up, and X is the degree of compression (1 to 9). 3 is the recommended value. See the Mozilla CVS page for more details, tools and links.


    4. A ZIP which currently contains the 1998/11/21 source tree. This is already outdated by the latest changes on the CVS tree. Eventually, this ZIP file will be automatically updated every evening.
  4. Set the following environment variables at the command line, with a script, or in config.sys if they're not already there:
  5. set TMPDIR=[drive:/path/to/tmp/space] <-- Note the use of / as the path delimiter.
    Also, add the following setting to config.sys if you do not have Visual Age C++ installed.
    set INCLUDE=[copy whatever you have for the environment variable C_INCLUDE_PATH]
    so that rc can find <os2.h>.

    Finally, to help configure get things right:

          set SHELL=cmd.exe
          set CC=gcc
          set CXX=gcc
          set MAKE=gmake
          set AWK=awk
          set RANLIB=echo
          set INSTALL=nsinstall

    Now, if necessary, reboot for the settings to take effect.

  6. Install or build NSPR:
  7. configure tests for the presence of NSPR (Netscape Portable Runtime) library, and fails if it can't find and link with it. You therefore either have to build NSPR, or install the binaries available at Hobbes and Leo in If you grab the zip, follow the installation instructions it contains. Otherwise, here's how to build NSPR.

    1. As the NSPR build uses static makefiles, you first have to set the right environment variables. The simplest way to do this is to create a .cmd file containing the following lines, fill in the value of MOZ_SRC (which should not include the root directory, e.g. MOZ_SRC=g:\dev if the source code is in g:\dev\warpzilla on your machine), and run it.

          set MOZ_OS2_TOOLS=EMX
          set MOZ_BITS=32
          set MOZ_DEBUG=1
          set MOZ_GOLD=1
          set MOZ_MEDIUM=1
          set MOZ_SRC=[drive:\path to warpzilla root directory]
          set NO_SECURITY=1
          set NSPR20=1

      Do not set these environment variables in config.sys because running configure sets them for the GeckOS/2 build, and assumes they are not set (i.e. a vanilla shell).

    2. Then start by making warpzilla/config with:

        cd config

      This builds nsinstall.exe and bsdecho.exe which end up in warpzilla\dist\os24.0_emx_dbg.obj\bin.

    3. Next, with nsinstall.exe in your PATH:
      cd warpzilla\nsprpub
    4. Finally, make sure the three 3 new DLLs (nspr21.dll, plc21.dll, and plds21.dll) you should now find in warpzilla\dist\os24.0_emx_dbg.obj\bin are in your LIBPATH by either copying them to a directory in LIBPATH, or adding [drive:]\warpzilla\dist\OS24.0_EMX_DBG.OBJ\LIB to your LIBPATH in config.sys. You CANNOT use SET ENDLIBPATH or BEGINLIBPATH. (why not? we're not sure...)

    Now you're all set to spawn the lizard...

    Building GeckOS/2

    1. Open an OS/2 command prompt, change to the drive and root directory of the source tree and launch gbash.

    2. At the gbash prompt, run autoconf, which reads warpzilla/ and writes warpzilla/configure. It runs quietly, i.e. no output messages. If after a few seconds you're back at the gbash prompt, everything's (probably) okay. N.B. Do not run autoconf --auxfiles as instructed in the autoconf doc (acemx.html) because it'll copy config.guess and config.sub to the wrong directory. The Warpzilla versions of those files (in warpzilla/build/autoconf/config.guess have been patched to recognize OS/2, so it's completely unnecessary.

    3. Create a directory for your build tree. Although this step is only mandatory if you want to build more than one version of GeckOS/2 (e.g. emx and vacpp), if you opt to build in the source tree, you'll likely get "no such directory" failures at certain points where files get copied to the build tree so that rc can find them. You can name the directory anything you want, but the "standard procedure" is:

      mkdir obj-`build/autoconf/config.guess` <-- Backticks, not single quotes!

      which creates a directory named obj-i386-os2.40. This will soon be changed to obj-i386-os2.40_emx, [...]_vacpp or [...]_pgcc to support multiple side-by-side builds.

    4. Now cd to your build directory and run configure.
      ../configure --without-x [options] --with-nspr=[path]
      configure options: For the full list of options, enter "configure --help | more". For us, --without-x and --with-nspr are mandatory or configure will fail. --enable-dom works, as does --enable editor which builds ender.dll. For development, you'll want to use --enable-debug.

      To reduce build time and redundancy, you can use --with-jpeg=, --with-zlib= and --with-png= if you have or install those libraries. The versions must be jpeg 6b, zlib 1.1.3 and png 1.0.2 because configure checks and won't use a version older than the one in the mozilla tree. The path you set (and this also applies to --with-nspr) must be a directory with an /include and a /lib subdirectory. For example, if you have d:\imagelibs\jpeg6b\include and lib, you would use --with-jpeg=d:/imagelibs/jpeg6b. These paths are passed to gcc for the -I and -L flags. Equally important, the corresponding dlls must also be in your LIBPATH so the linker can find them.

      We haven't yet had a chance to test the packages of jpeg, zlib and png libraries available at the XFree86 OS/2 site; we used our own builds of the original sources. We have no reason to believe those distributions won't work. If you try them before we do, please let us know that they can be used and provide details should you encounter any problems. The package recently uploaded to Hobbes will not work with the Warpzilla code which expects jpeg.dll rather than jpeg6b.dll; it has been withdrawn from distribution to avoid creating confusion and possibly duplicating an existing release. If, however, we find out that for some reason the XF86 packages do not work with Warpzilla, we will make compatible versions available.

      Running configure first checks your system type, then for the compiler and various tools, and finally for headers and libraries. If it fails, you can examine the compiler or linker input and output in config.log. If everything's okay, configure next writes config.status and creates a "mirror tree" holding all the makefiles necessary to build Warpzilla, but separate from the actual source.

      A few random tips:

      • You don't have to run configure every time you want to build GeckOS/2. Just the first time, then whenever,, or your system change, or whenever you change options. In that case, delete config.cache before running configure.
      • Once configure starts creating the Makefile mirror tree, it's hard to stop with Ctrl-C because it just keeps going...and going...and going...
      • To refresh your Makefile tree, which you have to do when a changes, run config.status.
      • And, just in case you haven't noticed, gbash saves its history on disk (in home/.bash_history) so you can use the up-arrow to scroll back to a configure command instead of retyping it.

    5. When configure is done, enter


      to build the beast. Anywhere from 45 minutes (on a PII-266, 160MB RAM) to several hours later, you should end up with all the binaries in warpzilla/obj-i386-os2.40/dist/OS24.0_AC.OBJ/bin and libraries in [ditto]/lib.

      The build loops through three cycles: export, in which headers are copied from the various modules primarily into warpzilla/dist/include and NSPR is built; libs during which the remaining components get built; and install which builds vreg.exe and several tests while (re)copying binaries, libraries and resource files to warpzilla/dist/OS24.0_AC.OBJ subdirectories.


    Running GeckOS/2:

    Upon launch, GeckOS/2 tries to load so you should get online first before entering "xpviewer". Otherwise, select File/Samples from the menubar and load any of the demos, or open a local file. Enlarge to display the toolbars, explore, enjoy, and contribute to its development if you can.

    Useful links:

    • For the latest Warpzilla NGLayout developments, John Fairhurst's NGLayout OS/2 site is homebase.
    • For NGLayout in general, the mozilla site is a goldmine.
    • For XPViewer testing, try the testcases or really funky demos.
    • Some older but still useful general build and NSPR information, tools and links can be found on Henry's pages.

    Please report build problems and bugs to our newsgroup.

    - Henry Sobotka & Joan Touzet
    Last modified: 1998/12/12 23h55 
    Copyright © 1998 Netscape Communications Corporation