Pick a Compiler, but Not Any Compiler

Compiling Mozilla on Windows

The Mozilla build infrastructure has been switching from Visual C++ 6 to Visual Studio 2005 (VC8) on the Mozilla trunk. This has bred some confusion about which compiler should be used to build various branch(es). I’ve made a chart that will hopefully ease the confusion:


Gecko 1.9
Firefox 3

Gecko 1.8.1
Firefox 2

Gecko 1.8
Firefox 1.5.0.x



Yes (Official)

Yes (Official)

VC7 (Visual Studio 2002)

Not really



VC7.1 (Visual Studio 2003)




VC8 (Visual Studio 2005)

Yes (Official)



If you want a single compiler to compile all the active branches, you should use VC7.1.

Compiling Mozilla on Linux

I also have some interesting developments to report in GCC-land: a large patch by Jason Merrill (RedHat) landed on GCC trunk which fixes a whole bunch of GCC visibility bugs (previous post about these issues). Unfortunately, Jason added some additional restrictions on the use of types with hidden visibility which means that Mozilla doesn’t even compile using GCC trunk. I’ve been in email contact with Jason and hopefully we’ll have things worked out shortly.


Mozilla uses a common pattern of hidden-visibility types which are passed across DSO boundaries using default-visibility accessors:

class __attribute__ ((visibility ("hidden"))) nsISomething : public nsISupports
  NS_IMETHOD DoSomething();

__attribute__ ((visibility ("default"))) nsresult GetSomething(nsISomething **aResult);

This declaration causes a warning in GCC trunk (visibility attribute requests greater visibility than its type allows) and makes the GetSomething symbol hidden. Since the nsISomething interface is composed entirely of virtual functions, however, there is not a problem passing it across DSO boundaries (no symbol lookups are involved calling a virtual method).

Compiling Mozilla on Mac

I’m not going to say much about doing UB builds, other than it works and Mark Mentovai is primarily responsible… we basically do a PPC build and a Mactel build and glue them together into a UB build.

But, now that we’re using GCC4 and MacOS10.4 on at least some Mac platforms, there are some great optimizations we can do: GCC4 on mac supports hidden visibility just like it does on Linux, which will allow us to stop exporting a whole slew of symbols. This doesn’t have the same performance benefits as it does on ELF systems, but it does make embedding a whole lot less dangerous, because you won’t accidentally be picking up symbols that weren’t meant for you.

In addition, MacOS 10.4 added a new kind of dynamic library dependency: @loader_path/libnspr4.dylib. Unlike @executable_path, which looks for shared library dependencies relative to the application being run, @loader_path looks for shared library dependencies relative to the library currently being loaded. This is absolutely fantastic, because it allows code to dynamically load /Library/Frameworks/XUL.framework/Versions/Whatever the latest version is/libxpcom.dylib and dependencies to libnspr4.dylib will be resolved automatically!

I haven’t integrated either of these new features with the Mozilla build system yet, but I’m hoping to relatively soon.

Atom Feed for Comments 7 Responses to “Pick a Compiler, but Not Any Compiler”

  1. Robert Accettura Says:

    I did manage to get the MOZILLA_1_8_BRANCH compiling with VC 2005 (Express Edition). But my “hack” isn’t very good. The issue I encountered was fixed by coping the .manifest files over to the bin directory. Yea, that’s lame, but it seems to be working thus far. We’ll see how much milage I get off of it.

    I don’t mean to undermine the above… but if your stuck with VC 2005, perhaps that hint can help you out.

  2. Javier Pedemonte Says:

    Unfortunately, I believe doing both of those Mac fixes would make the resulting build only work on 10.4+. This is fine for Mac/Intel, but we still support 10.2 and 10.3 on Mac/PPC.

  3. FP Says:

    Are the VC8 fixes too risky for the 1.8 branch?

  4. Ludovic Hirlimann Says:

    would you mind posting the same charts for Mac OS X as the one you posted for Windows. I can’t build xulrunner on mac os x 10.3.9 with the 10.2.8 sdk. What are the minimums required to build both os and SDK wise.


  5. Benjamin Smedberg Says:

    Javier, yes I was planning on taking those linker changes on the mactel side only.

  6. Antony Mawer Says:

    Has anyone tried building with ICC (Intel C/C++ compiler) to see what the performance with it may be, as opposed to MSVC/GCC? At the very least, this may be of interest for the release builds…

  7. lilmatt Says:

    Note that there is an outstanding bug with the gdb Apple bundled with the latest Xcode and those 10.4 builds without symbols. Basically, debugging them sucks, and gdb may Bus Error out before it finishes trying to load the symbols. I had to do some seriously ugly build-fu to get symbols in an Intel Mozilla build working. Perhaps striping symbols can be the default, but an option we can –disable?


Leave a Reply