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:

Branch	HEAD Gecko 1.9 Firefox 3	MOZILLA_1_8_BRANCH Gecko 1.8.1 Firefox 2	MOZILLA_1_8_0_BRANCH Gecko 1.8 Firefox 1.5.0.x
VC6	No	Yes (Official)	Yes (Official)
VC7 (Visual Studio 2002)	Not really	Yes	Yes
VC7.1 (Visual Studio 2003)	Yes	Yes	Yes
VC8 (Visual Studio 2005)	Yes (Official)	No	No

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.

Details

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
{
public:
  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.

This entry was posted on 12 Jul, 2006 at 1:44 pm and is tagged with . Trackback.