Setting Up an MSVC Toolkit Firefox/Thunderbird Build Environment

Tags: — Jeff @ 17:03

Last updated: not recently enough for me to consider giving it a good last edited date. 🙁 I’d hoped to update it over January, but it didn’t happen. The plan is for the new graphics backend based around Cairo to land really soon now (it was scheduled for the end of January), and given that I had problems compiling a Cairo-based build, I’m waiting until that backend’s been switched on and all the build bugs have been worked out before attempting to update these instructions. (Yes, compiling without Cairo should still work as long as the non-Cairo code remains in the tree, but Cairo’s the future, and there are a good number of bugs which will only ever be fixed in Cairo-based builds. Additionally, I expect the non-Cairo code to be removed from the tree fairly soon after Cairo is enabled.)

Note: I’ve moved comments over to a separate page to de-clutter this page and make it easier to use.


Microsoft recently released a free version of the Visual Studio C++ compiler. This free version is (interestingly enough) fully functional. Compiled code created with it is binary-compatible with code used in downloadable plug-ins like Java, Flash, Shockwave, and others (something which can’t be said for builds created using MinGW and gcc on Windows). The free compiler can also be used to build Mozilla applications. This document describes how a complete, optimized build environment can be created from nothing but a Windows command line.

This probably works for other Mozilla-based applications, like Sunbird, the Mozilla Suite, and others. However, I’ve only tested Firefox and Thunderbird so far. Also, note that your mozconfig file will need to be at least somewhat different if you intend to build an application other than Firefox. Hopefully I’ll have time to make the directions more generic, but I don’t know when that’ll be. Also, these directions only apply to trunk builds; you may have to do other bits of hackery or use older versions of some tools in order to build older code.

Pros and Cons

  • Pros
    • Free!
    • Build your own – don’t wait for the nightlies!
    • Binary compatibility with nightly builds, so 3rd-party plug-ins work
  • Cons
    • You need a newish version of Windows — possibly Windows XP
    • Huge download size — almost certainly not for dialup
    • You can’t build ActiveX (exact reasons unknown, but the build doesn’t complete)
    • You can’t build the IE migrator, and you have to apply a patch to the source to keep from trying to build it
    • With an objdir build (the generally recommended way to build), you’ll have to manually tweak some path creation for browser/app/profile/extensions/{*}, because the build process creates the directories without the curly braces. This may no longer be true because of a recently fixed bug, but I haven’t tested.
    • No IDE for development work
    • Debugging the build may be limited, if only because no GUI debugger exists (I don’t debug, so I don’t know how limited)


  • Windows XP (Windows 2000 may or may not work, but lower versions will not)
  • A decently-sized hard drive with free space (I recommend at least 10GB free space)
  • Lots of RAM (1GB recommended, should work with less)
  • A fast processor (recommended, but not required — I’ve compiled on a PII 450MHz computer before)
  • A broadband Internet connection (recommended due to the size of what needs to be downloaded, but not strictly required)

Getting Environment-Specific Tools

Download and install the following Windows build environment software. For simplicity, choose the default installation locations for everything. At some point in the future I may edit these instructions to work with non-default install locations, but for now you’ll have to use the defaults.

  • Microsoft .NET Framework Version 1.1 Redistributable Package (must be installed before the .NET SDK)
  • Microsoft .NET Framework SDK Version 1.1
  • Microsoft Windows SDK:
    1. Using Internet Explorer, visit the MS SDK Update site.
    2. Select Downloads > Install from the in-page dropdown menu.
    3. Select the Windows SDK checkbox. The sample code and documentation options from the SDK subsections are not needed.
    4. Finish installing the selected options.
  • Microsoft Visual C++ Toolkit 2003
  • Compiler-specific versions of glib and libIDL:
    • Extract to C: (so that the file DLLs reside in C:\vc71\bin).
  • MASM32
    • (I have heard of nebulous licensing concerns here regarding MASM32 usage with open source software, but I have read the relevant documents and believe no such problems exist. That said, I’m no lawyer, and you probably shouldn’t be listening to me if you really want to find out for certain. I’m in contact with someone investigating this, so I’ll update this page as I learn more.)

Getting General Windows Build Environment Tools

  • Cygwin
    1. Set the package location to a location that won’t be overwritten. The location is irrelevant to getting a working build, but it’ll make updating your Cygwin environment easier in the future should you choose to do so.
    2. Install for All Users with a default text file type of Unix.
    3. In the package list dialog, click on View once to enter View All mode.
    4. Select the following packages:
      • ash: UNIX-like command line interpreter shell
      • cvs: used to download the source code
      • coreutils: GNU core utilities (includes fileutils, sh-utils, and textutils)
      • diffutils: file comparison utilities
      • findutils
      • gawk: pattern matching language
      • grep: text search tool
      • patch: used to tweak the source code to make it compile
      • sed: a search and replace program
      • unzip: commandline zip file extractor
      • zip: zip file creator
    5. Change the following packages:
      • make: select version 3.79.1-7, because make 3.80 breaks the build (this may no longer be true, as noted below in the ActiveState Perl section, but I don’t intend to update this until I’ve had a chance to test for myself).
      • perl: deselect it, because we’ll use ActiveState Perl (it’s needed to build installer builds)
  • ActivePerl, a Windows version of Perl
    • Get ActivePerl 5.6.1 or the latest smaller-numbered ActivePerl — 5.8.3 may be broken right now because of bug 232003. This bug was recently marked as RESOLVED FIXED, however, so this problem probably doesn’t exist any more. That said, I won’t update this until I have a chance to test for myself.
  • Netscape wintools
    • Unzip to a temporary directory and open a Windows command prompt there.
    • Run SET MOZ_TOOLS=C:\moztools.
    • Run install.bat inside buildtools\windows.
  • Creating Build Configuration Files

    1. Create the directory C:\moz. Save this build environment script as C:\moz\buildsetup.bat. (Note: you probably need to edit this file as suggested in comment 48; this will be fixed in the next instruction update.)
    2. Open a Windows command prompt and move to C:\moz. Type in cvs login, and use the password anonymous at the prompt (ignore any error message you may get about .cvspass not existing). Then type cvs co mozilla/browser/config mozilla/client.mk at the command prompt.
    3. Create a .mozconfig build file using the Firefox build instructions. I recommend you use my .mozconfig, because it already includes the default options needed to disable the things you can’t build with a free setup (see above).

    Downloading and Building the Source

    1. Move to C:\moz\. Run buildsetup.bat there to set up all the environment variables. Next, type cd mozilla to move into the source code directory. Run make -f client.mk checkout to download the latest Firefox source from the trunk. You may want to check the Firefox tinderbox to see whether the Windows tree is burning or not; if it is you almost certainly won’t be able to finish your build.
    2. Patch the source to make it build with the build tools. Download the build patch to C:\moz\patch.diff, and apply the patch by moving to C:\moz and doing set POSIXLY_CORRECT=1;patch -p0 < patch.diff;.
    3. Run make -f client.mk build. Wait a bit and test your new Firefox!


    I just received the following email recently:

    Using the procedure outlined on [this page] I was able to build a semi-working Sunbird 0.2.

    The catch is that it didn’t complete until ActiveX was disabled in .mozconfig, and the OBJDIR option was removed. Please advise if you are able to pin down why ActiveX doesn’t work that way.

    Make 3.80 doesn’t work in any case (stops in a different place), but 3.79 is fine. The OBJDIR version still doesn’t make a subdirectory in extensions with curly braces, even wtih the recommended versions of make
    and ActivePerl. Someone may have a patch for Firefox, but that doesn’t help me build Sunbird. So I left make at 3.79 and updated ActivePerl to version (same issue – I don’t think it’s the problem).

    I used your .mozconfig but changed the top line to . $TOPSRCDIR/calendar/sunbird/config/mozconfig and it goes all the way through.

    However, Print Active Calendar doesn’t work right, since it apparently depended on ActiveX to do its job. You get a huge blank dialog box that fills the screen.

    A clean compile using VC6 (but also using ActivePerl 5.8.6 and MASM32) works fine, including the print dialog. Haven’t tried an OBJDIR version yet.

    So, I have word that this process pretty much works for Sunbird as well as for Thunderbird and Firefox. Once again, YMMV, but if you feel like trying this on Sunbird you can feel a little bit better because if one person’s done it, it’s not impossible.

    Another Update!

    After sending back a response to the above email, I got this reply:

    Just a follow up then. The problem with the print dialog vanished after I went into directory
    xpfe\communicator and did another make, as recommended on http://www.mozilla.org/projects/calendar/sunbird_build.html.

    So I don’t know the effect of disabling ActiveX via .mozconfig in terms of functionality. It acts fine as far as I can tell, just like one I build with VC6.