Trying to build SeaMonkey

[Lemon Juice]

I'd like to be able to build SeaMonkey from source on my Windows 7 computer and obviously I'm running into issues and this doesn't look like an easy task. I've installed Visual Studio Express 2013, Outlook 2010 MAPI Header Files, MozillaBuild and downloaded the source code from comm-central by following this guide.

My .mozconfig looks like this:

Code: Select all

ac_add_options --enable-application=suite
mk_add_options MOZ_OBJDIR=c:/msrc/comm-central/src/obj-sm-release

And I run the process in this way, capturing output in a log file:

Code: Select all

mozmake -f client.mk > build.log 2>&1

The build process ends after a few minutes and I can spot this error at the end of the log:

Code: Select all

mozmake[4]: Entering directory 'c:/msrc/comm-central/src/obj-sm-release/extensions/inspector'
c:/msrc/comm-central/src/mozilla/config/config.mk:47: *** Variable PREF_JS_EXPORTS is defined in c:/msrc/comm-central/src/obj-sm-release/extensions/inspector/Makefile. It should only be defined in moz.build files.  Stop.
mozmake[4]: Leaving directory 'c:/msrc/comm-central/src/obj-sm-release/extensions/inspector'
c:/msrc/comm-central/src/mozilla/config/recurse.mk:82: recipe for target 'extensions/inspector/export' failed
mozmake[3]: *** [extensions/inspector/export] Error 2

Any idea what went wrong?

Another problem - this happened earlier when I was trying to build an earlier 2.32b3 release from source downloaded via mozilla ftp. For some reason I didn't get the inspector error above but another error later in the process:

Code: Select all

mozmake[4]: Entering directory 'c:/msrc/comm-beta/obj-sm-release/mailnews/import/outlook/src'
mkdir -p '.deps/'
MapiApi.cpp
c:/msrc/comm-beta/obj-sm-release/_virtualenv/Scripts/python.exe -m mozbuild.action.cl  cl -FoMapiApi.obj -c -I../../../../dist/stl_wrappers  -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DOSTYPE=\"WINNT6.1\" -DOSARCH=WINNT -DNO_NSPR_10_SUPPORT -Ic:/msrc/comm-beta/mailnews/import/outlook/src -I. -Ic:/msrc/comm-beta/mailnews/import/outlook/src/../../src -I../../../../dist/include  -Ic:/msrc/comm-beta/obj-sm-release/dist/include/nspr -Ic:/msrc/comm-beta/obj-sm-release/dist/include/nss        -MD            -FI ../../../../dist/include/mozilla-config.h -DMOZILLA_CLIENT  -TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4482 -wd4800 -wd4819 -we4553 -GR-  -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -O1 -Oi -Oy   -Fdgenerated.pdb   c:/msrc/comm-beta/mailnews/import/outlook/src/MapiApi.cpp
MapiMessage.cpp
MapiApi.cpp
c:\msrc\comm-beta\mailnews\import\outlook\src\MapiApi.h(16) : fatal error C1083: Cannot open include file: 'mapix.h': No such file or directory
c:/msrc/comm-beta/config/rules.mk:966: recipe for target 'MapiApi.obj' failed
mozmake[4]: *** [MapiApi.obj] Error 2

I suppose this was something to do with MAPI Header Files but I had those installed and I added C:\Office 2010 Developer Resources\Outlook 2010 MAPI Headers to the INCLUDE environment variable and then tried also with the PATH variable but still the compiler apparently couldn't find mapix.h. What do to about it?

I haven't yet experienced the mapix.h error in trying to build from comm-central today but I suspect I may get to it if I manage somehow to go past the first error with the inspector.

Edit: As to the MAPI issue I think I missed this part from the instructions: "You should copy the header files to a Windows SDK include directory so that the build process will find the files, for example to C:\Program Files (x86)\Windows Kits\8.1\Include\shared.". I've done that now so I hope at least this problem will go away. We'll see..

[barbaz]

No idea if this will work, but given my experiences with self building SeaMonkey, try deleting your objdir and changing your objdir path to

Code: Select all

c:/msrc/comm-central/objdir

Tip: If you're new to self building c-c I highly recommend you start with changesets you *know* can generate a successful build (meaning, a c-c changeset / m-c changeset from which someone else has successfully made a build for Windows). It happens a fair amount that changes in m-c break building from c-c.

[Lemon Juice]

Thanks for the tip. Yeah, I've never built SM before so it sounds reasonable to try tested revisions first, indeed the c-c builds can have problems compiling if there is some unexpected bug in the unstable branch. I'll try experimenting with official releases for now.

[barbaz]

I'll try experimenting with official releases for now.

FYI, you won't get quite the same result if you build from a source tarball vs. a cloned comm-release updated to the specific revisions used for building the release. Build from the tarball won't know its own build revisions, which means you don't see them in about:buildconfig and the Nightly Tester Tools add-on partially breaks.
Don't know if you care about that or not.

[Lemon Juice]

I don't care about this now but it's good to know, thanks.

While we are at it - if I checkout (switch to) a different comm-release or comm-central revision to build from what do I do about the other dependencies that are fetched with python client.py checkout? Do I have to run this command each time after switching revisions? Or should I clone to a new directory and start from scratch to avoid some remnants from revisions I used earlier?

[barbaz]

if I checkout (switch to) a different comm-release or comm-central revision to build from what do I do about the other dependencies that are fetched with python client.py checkout?

Personally I just worry about comm-* revision and mozilla-* revision, and use hg update to set the repositories to the revisions I'd like to build from. I haven't had to worry about the revisions of the other 'subrepositories' (e.g. DOMi, Chatzilla) yet...

Do I have to run this command each time after switching revisions?

python client.py checkout updates the repositories to the latest revision after it's pulled changes, so no.
If building from a specific revision, you only need to run it once, *before* setting the repositories to the revisions you want to build with, so that you have all the repositories comm-central depends on.

Or should I clone to a new directory and start from scratch to avoid some remnants from revisions I used earlier?

In order to get rid of remnants, all you have to do is delete your entire objdir, and yes that's a good idea. The presence of an objdir from a prior build can make the difference between a build working and a build failing.

[Lemon Juice]

Thanks. However, I'm experiencing more serious problems:

Code: Select all

   Creating library xul.lib and object xul.exp

LINK : warning LNK4199: /DELAYLOAD:dbghelp.dll ignored; no imports found from dbghelp.dll

nsMemoryCacheDevice.obj : fatal error LNK1318: Unexpected PDB error; OK (0) ''

d:/msrc/2.32/mozilla/config/rules.mk:829: recipe for target 'xul.dll' failed
mozmake[4]: *** [xul.dll] Error 1318

I'm on windows 7 32-bit with 3 GB of RAM and from what I've read this might not be enough to build mozilla. Memory usage at the final stage goes to the maximum and then the whole thing stops. Is there a way to get it to build regardless? If not I think I'll have to give it up for now until I upgrade my system some time in the future.

[barbaz]

I've only built SeaMonkey on Mac OS X and Linux, I've never even attempted building on Windows, so can't help you there, sorry.

From reading those links it sounds like that issue is a compiler problem, maybe try building with a different compiler/linker? (gcc can build SeaMonkey successfully on Linux with only 2 GB RAM...)

[Lemon Juice]

From reading those links it sounds like that issue is a compiler problem, maybe try building with a different compiler/linker? (gcc can build SeaMonkey successfully on Linux with only 2 GB RAM...)

The official Mozilla document says 2 GB of RAM minimum is needed so I thought this would work with 3 GB. But perhaps that page was not updated for quite some time and 2 GB might have been correct maybe 5 years ago.

I believe you when you say you can build successfully on 2 GB RAM on Linux - all the MS dev tools look like enormous resource hogs eating disk space and memory like crazy so I suppose a unix compiler might perform much better. Unfortunately, I have no idea how to use a different compiler because there seem to be no instructions on how to do that on windows. I am a novice at this so following the detailed Mozilla instructions is enough of a challenge for me.

[barbaz]

Again, I'm just making wild guesses, but this page may help you https://developer.mozilla.org/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl

[Lemon Juice]

Thanks, I didn't find it before. I'll give it a try when I get more time to play with it.

[Philip Chee]

The build process ends after a few minutes and I can spot this error at the end of the log:

Code: Select all

mozmake[4]: Entering directory 'c:/msrc/comm-central/src/obj-sm-release/extensions/inspector'
c:/msrc/comm-central/src/mozilla/config/config.mk:47: *** Variable PREF_JS_EXPORTS is defined in c:/msrc/comm-central/src/obj-sm-release/extensions/inspector/Makefile. It should only be defined in moz.build files.  Stop.
mozmake[4]: Leaving directory 'c:/msrc/comm-central/src/obj-sm-release/extensions/inspector'
c:/msrc/comm-central/src/mozilla/config/recurse.mk:82: recipe for target 'extensions/inspector/export' failed
mozmake[3]: *** [extensions/inspector/export] Error 2

That's Bug 1128291 - Move PREF_JS_EXPORTS to moz.build in DOM Inspector

Which should be fixed if you do another

Code: Select all

client.py checkout

Phil

[Philip Chee]

Thanks. However, I'm experiencing more serious problems:

Code: Select all

   Creating library xul.lib and object xul.exp

LINK : warning LNK4199: /DELAYLOAD:dbghelp.dll ignored; no imports found from dbghelp.dll

nsMemoryCacheDevice.obj : fatal error LNK1318: Unexpected PDB error; OK (0) ''

d:/msrc/2.32/mozilla/config/rules.mk:829: recipe for target 'xul.dll' failed
mozmake[4]: *** [xul.dll] Error 1318

I'm on windows 7 32-bit with 3 GB of RAM and from what I've read this might not be enough to build mozilla. Memory usage at the final stage goes to the maximum and then the whole thing stops. Is there a way to get it to build regardless? If not I think I'll have to give it up for now until I upgrade my system some time in the future.

Sounds like Bug 1110236 - Intermittent "mozmake.exe[6]: *** [xul.dll] Error 1318" after "fatal error LNK1318: Unexpected PDB error"

Phil

[Philip Chee]

Again, I'm just making wild guesses, but this page may help you https://developer.mozilla.org/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl

clang won't help you since the error is at the linking step and for that you still need the MSVS linker.

Phil

[Lemon Juice]

Thanks for the info. It's good to know the first bug was fixed but is it reasonable to expect SM will build on a 32-bit Win7 with 3GB of RAM? I was trying to build SM 2.32 three times and the linking stage failed. If clang won't change anything then I'm not sure if it's worth even trying in my current setup...