Mozilla Build FAQ
From MDC
Build Documentation:
- Requirements
- Source
- Configuration
- Build
- Frequently Asked Questions
- More...
Contents |
See also:
- Debugging Mozilla on Windows FAQ: Tips on how to debug Mozilla on Windows
[edit] General questions
- Which systems are supported Mozilla build platforms?
- See Supported build configurations.
- What type of build system does Mozilla use?
- Mozilla uses a thin GNU configure layer on top of a legacy Netscape recursive makefile build system on all platforms. Like most configure-based projects, it uses GNU autoconf to generate the configure script. GNU make is used to drive the build process.
- Why use GNU make?
- GNU make has been ported to a lot of systems. This makes porting Mozilla to those systems a bit easier. Using only the subset of make features that are supported by the native make program on 10 different platforms would make the build system unnecessarily complicated.
- Will any other version of make work?
- No. The Mozilla makefiles use GNU make specific features which will only work with gnu make.
- Why aren't you using automake?
- Part of Netscape's legacy system involved using GNU make's -include feature to include a common set of rules from a handful of files in every Makefile that needed to use them. With this centralized rule system, one of the primary selling points of automake was made inconsequential. Also, at the time, Mozilla's method of building libraries did not mesh well with libtool.
- What happened to the nmake and CodeWarrior build systems?
- They no longer exist in the current tree. nmake build support was dropped during the Mozilla 1.2a release cycle. The mac cfm build system was dropped along with OS9 support shortly after the Mozilla 1.3 release.
- Why not ant, tmake, scons or insert your favorite build system here?
- Mainly, because no one has implemented these systems for Mozilla. When Mozilla was first open sourced, it only contained the legacy Netscape system. The autoconf layer was added on a branch and maintained in parallel for 6 months before it became the standard build system for the unix build.
- If I wanted to implement my favorite build system for Mozilla, would Mozilla start using it? I don't want to waste my time if you aren't going to use it.
- There's no guarantee that any code written for Mozilla will be accepted into the default tree. Any build system that is implemented would have to show that it's better overall than the current build system. Speed, flexibility, portability and the ability for a large group of developers who have 3+ years experience with the current build system to easily transition to the new system would be the major factors in deciding to switch. If you are serious and willing to do lots of work, contact User:Benjamin Smedberg to discuss the details of your proposal.
- Why doesn't Mozilla support autoconf 2.5x?
- Simply put, autoconf 2.5x does not offer anything to make the upgrade worth the effort. Autoconf 2.5x is not backwards compatible with autoconf 2.13 and the additional restrictions made by the newer versions of autoconf would require a major rewrite of the Mozilla build system for questionable gain.
Some of the 2.13 features, such as the ability to pass additional arguments to sub-configures, are not available in 2.5x. People have asked repeated about those features on the autoconf mailing list without any favorable response. Rewriting the configures of the sub-projects of Mozilla (NSPR & LDAP) is not an acceptible tradeoff. The sub-projects are also standalone projects and forking an entire codebase because of a build system incompatiblity is silly.
- Why doesn't NSS use autoconf?
- The NSS project is also used outside of the Mozilla project and the NSS project members did not feel that moving to autoconf was worth the cost. See bug 52990 for details.
- Can I build multiple Mozilla-based projects from a single source tree?
- Yes! Each project must be built in its own objdir.
- What is an objdir?
- An objdir build refers to the process of creating the output files in a different place than where the source lives. This is a standard feature of most configure-based projects. It allows you build for multiple configurations, including multiple platforms if you use a network filesystem, from a single source tree. It also avoid tainting your source tree so that you know that the files in your tree have not been modified by the build process.
If you run configure by hand, you can use the standard method of creating an empty directory any place on the disk, changing to that directory and running /path/to/mozilla/configure from there.
mkdir obj-debug cd obj-debug ../mozilla/configure
If you use client.mk to build, you can add the following to your mozconfig file:
mk_add_options MOZ_OBJDIR=/path/to/objdir
- Can I cross-compile Mozilla?
- Yes, see the Cross-Compiling Mozilla document for details. No, Canadian Cross-Compiling is not supported.
- How can I test out a build of just certain files, instead of the whole tree, while I'm changing code?
- Change into your objdir, change down to the specific directory where you want to build (the directory structure of the objdir matches the structure of the source dirs), and type just "make" (or "gmake" if necessary). This only works if you find a directory that contains a "Makefile" (the equivalent directory in the source tree will contain a "Makefile.in"). If you want to get even more specific than that, you can try "make <filename>.obj". See Incremental Build.
- Do parallel (make -j) builds work for Mozilla?
- Yes. See the GNU Make Parallel Execution manual entry for optimal usage.
If you get obscure build errors when using parallel building (especially when using -j instead of -jN to run as many tasks in parallel as possible), try reducing the number of parallel tasks by decreasing N (or, if you used unlimited parallelism, add a small number N to -j).
Parallel building with -j4 and -j8 seems to work well.
- How do I force the build system to pick up any of the changes made to my mozconfig file?
- Touch any of the configure scripts in the tree. There is no explicit dependency upon the mozconfig file as the file can reside anywhere via the MOZCONFIG environment variable.
- error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418, <STDIN> line 9.
- You are trying to build Firefox without following the instructions on Configuring Build Options. In particular, your mozconfig file must source the Firefox default mozconfig file:
. $topsrcdir/browser/config/mozconfig # add your custom additional options here
- Initial cvs checkout fails with the message: cvs [checkout aborted]: *PANIC* administration files missing
- You cannot create a cvs tree under a directory named "CVS". This is a feature/bug of cvs. cvs expects to find certain administration files under the CVS directory and will complain if they are missing.
- Error: ../coreconf/rules.mk:406: target `c' doesn't match the target pattern
- This only happens on certain versions of Cygwin. Try building with MozillaBuild instead. If you really want to make this work on Cygwin, you need make 3.80 and no other version like 3.81.
- make 3.80 is no longer available in the Cygwin setup installer, so you'll have to find it yourself. You can google for make-3.80-1.tar.bz2 and it's also available here.
[edit] Mac-specific questions
- Can I build a Mozilla application as a Universal Binary?
- Yes. See Mac OS X Universal Binaries for instructions.
- How can I turn on distcc to help compilation ?
- TBA.
- Does Mozilla build on UFS?
- Yes, since bug 157036 has been fixed.
- Does Mozilla run on UFS?
- Yes.
- Can I use CodeWarrior to compile the Mach-O build?
- No, CodeWarrior is dead. See bug 119589 for details.
- After rebuilding e.g. layout, how do I make my FirefoxDebug.app reflect that change?
- make -C browser/app.
For common Mac build errors and additional troubleshooting tips, see Troubleshooting in Mac OS X Build Prerequisites.
[edit] Win32-specific questions
- configure: error: installation or configuration problem: C compiler cannot create executables.
- Look at the
config.login the obj... directory. Try checking to make sure your PATH variable includes all the necessary directories. If you are using mozilla-build, then you need to start ming32 with one of thestart-msvc*.batfiles. If your build environment has changed, you may need to delete your config.cache file (in your mozilla or object directory) and then build again.
- xpt_link.exe: cannot find msvcr80d.dll.
- This occurs with option
--enable-optimize=-Odto disable any optimizations. The xpt_link.exe tool is also created using this-Odoption. To fix this, copyobj-dir/xpcom/typelib/xpt/tools/xpt_link.exe.manifesttoobj-dir/dist/bin. There is another manifest file there, for xpt_dump.exe. Copy that as well. This error will probably appear for any compiled tool that is used during the build process when-Odis specified. To copy all manifest files to thedist/bindirectory, issue:find ./ -iname *.exe.manifest -print0 | xargs -0 -t -i cp {} dist/binfrom theobj-dir
Warning: This section is out of date (bug 391393). Try Windows Build Prerequisites instead.
- Is there a Microsoft Visual Studio project file to build Mozilla?
- No. You must use cygwin and GNU make.
- Can I run the build commands from cmd.exe?
- Yes. Make invokes the cygwin /bin/sh subshell to execute commands so it does not matter what shell is used to initially invoke make.
- cvs update: authorization failed: server XXXX rejected access -- used empty password; try "cvs login" with a real password
- You are mixing wincvs and MozillaBuild cvs. Use only one or the other.
- Make spits out a command not found error, or about not being able to find a .dtd file
- You probably used WinZip to unpack the source archive. Don't do that. WinZip, by default, doesn't unpack 0 length files from tar.gz archives. Use another utility, or use the pull script to checkout the files that WinZip didn't extract.
- No such file or directory errors from lines in your mozconfig
- This can be caused by your mozconfig file having Windows-style line endings. Convert them to UNIX-style and the error should go away.
- xpidl.exe crashes with an access violation
- This usually occurs because of a mismatch between your compiler and your glib and/or libIDL libraries. If you are using the standard MozillaBuild package you should not have these problems.
If you are building with Visual Studio .NET, then you must link against the VC7 built version of the glib & libIDL DLLs. For Visual Studio .NET 2003, use the VC7.1 versions. For Visual Studio 2005, use the VC8 versions.
The directory containing the versions of these libraries specific to your compiler must be in your PATH before any other version of those libraries. The .dll and .lib files must be executable (just chmod 755 them) or cygwin will not load them.
See Windows Build Prerequisites for more tips on building with VC7 and newer.
There are also some alternative static libraries available in bug 242870 that may be used instead of compiler specific libraries.
If you are building with VC6, then you must make sure that you are not using the VC7 libraries at buildtime or at runtime.
- configure: error: the midl major version, , does not match the compiler suite version, <Visual C++ version number> -- same for linker
- The cygwin tool "link.exe" for symbolic links is being confused for the object linker from the Microsoft compiler suite, or midl is not found respectively. Make sure that the Microsoft tools are before cygwin in your PATH (see instructions), or rename or remove /bin/link.exe. Note that cygwin may modify the path when its shell starts, so look at
exportin cygwin shell, too. - configure: error: installation or configuration problem: C compiler cannot create executables.
- Try checking to make sure your PATH variable includes all the necessary directories. If you are using MS Visual Studio, run vcvars32.bat (which sets your PATH, LIB, and INCLUDE variables). If your build environment has changed, you may need to delete your config.cache file (in your mozilla or object directory) and then build again.
- build error: ../coreconf/rules.mk:365: target `c' doesn't match the target pattern
- You used make 3.81 from the cygwin installer. You must use make 3.80. Please read the instructions.
- fatal error LNK1112: module machine type 'IA64' conflicts with target machine type 'X86'
- Try changing the order of the directories in your PATH, LIB, and INCLUDE variables. Move any directories that include "win64" or "IA64" (or "AMD64") closer to the end.
- LINK : fatal error LNK1104: cannot open file 'atlthunk.lib'
- According to this Microsoft forum thread, there is a different version of the Active Template Library (ATL) in the free Platform Software Development Kit (PSDK) than in Visual Studio. The ATL in the PSDK does not support 32-bit code, only 64-bit, whereas the Visual Studio ATL supports both and does not require atlthunk.lib. Apparently the atlthunk.lib file is not available and cannot be built from freely available tools, including the Visual C++ Toolkit and Visual Studio Express. You can either upgrade to the full version of Visual Studio to use its version of ATL, or you can workaround this problem by changing some code in atlbase.h (in \include\atl under the PSDK directory) as follows.
--- atlbase.h.old 2006-06-08 08:20:26.671875000 -0400 +++ atlbase.h 2006-06-08 08:13:26.578125000 -0400 @@ -283,7 +283,7 @@ } }; #pragma pack(pop) - +/* PVOID __stdcall __AllocStdCallThunk(VOID); VOID __stdcall __FreeStdCallThunk(PVOID); @@ -291,6 +291,11 @@ #define FreeStdCallThunk(p) __FreeStdCallThunk(p) #pragma comment(lib, "atlthunk.lib") +*/ + +// workaround for not having atlthunk.lib in PSDK or VC++ 2005 Express Edition +#define AllocStdCallThunk() HeapAlloc(GetProcessHeap(),0,sizeof(_stdcallthunk)) +#define FreeStdCallThunk(p) HeapFree(GetProcessHeap(), 0, p) #elif defined (_M_AMD64) #pragma pack(push,2)I also had to delete the object directory and compile from scratch in order for the compiler to pick up this change.
- compiling or building an executable with cygwin and VS6.0 results in FIND: Parameter format not correct
- There is confusion between System32 "find" and cygwin's /usr/bin/find. The desired find is cygwin's. This is caused by Path ordering. A few possible solutions are possible:
- temporarily rename system32/find.exe
- make sure cygwin path entry comes before system32 path entry
- I packaged Firefox via the installer: make -C ${OBJ_DIR}/browser/installer installer without any problems. Executing the resulting installer asks for a missing mozz.dll; installation fails
- Both Thunderbird and Firefox should be compiled with the --enable-static --disable-shared configure flags
- shlibsign.exe - Entry Point Not Found; The procedure entry point CERT_GetFirstEmailAddress could not be located in the dynamic link library nss3.dll.
- You may have multiple instances of nss3.dll on your machine and in your path. Run a search on your machine for all instances of this file. Move any instances found outside of your firefox build tree aside during the build and rename them back when the build is done.
- Random permission denied errors (if ZoneAlarm 7 free edition is installed)
- The free edition of ZoneAlarm 7 leaks just after starting the build process with the recommended build environment on Windows XP - vsmon.exe (ZoneAlarm monitor file) crashes, bash returns a permission denied error and the system becomes almost unresponsive. There may be other software firewalls causing leaks with similar symptoms!
You should uninstall ZoneAlarm 7 and try a different firewall software like Comodo or Jetico.
[edit] Mingw32-specific questions
- If the configure or build fails due to a missing w32api, add the mingw32's /include directory to the end of your INCLUDE environment variable. Mingw32 libraries or binaries should not be needed, only the headers.