MozillaZine

Trying to build SeaMonkey

Discussion of third-party/unofficial Firefox/Thunderbird/SeaMonkey builds.
Lemon Juice
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 1st, 2015, 3:29 pm

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..
Last edited by Lemon Juice on February 1st, 2015, 3:58 pm, edited 2 times in total.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

barbaz
 
Posts: 1686
Joined: October 1st, 2014, 3:25 pm

Post Posted February 1st, 2015, 3:45 pm

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.
*Always* check the changelogs BEFORE updating that important software!

Lemon Juice
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 1st, 2015, 3:56 pm

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.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

barbaz
 
Posts: 1686
Joined: October 1st, 2014, 3:25 pm

Post Posted February 1st, 2015, 5:50 pm

Lemon Juice wrote: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.
*Always* check the changelogs BEFORE updating that important software!

Lemon Juice
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 1st, 2015, 5:58 pm

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?
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

barbaz
 
Posts: 1686
Joined: October 1st, 2014, 3:25 pm

Post Posted February 1st, 2015, 6:18 pm

Lemon Juice wrote: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...

Lemon Juice wrote: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.

Lemon Juice wrote: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.
*Always* check the changelogs BEFORE updating that important software!

Lemon Juice
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 2nd, 2015, 7:20 am

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.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

barbaz
 
Posts: 1686
Joined: October 1st, 2014, 3:25 pm

Post Posted February 2nd, 2015, 11:23 am

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...)
*Always* check the changelogs BEFORE updating that important software!

Lemon Juice
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 2nd, 2015, 1:05 pm

barbaz wrote: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.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

barbaz
 
Posts: 1686
Joined: October 1st, 2014, 3:25 pm

Post Posted February 2nd, 2015, 1:13 pm

*Always* check the changelogs BEFORE updating that important software!

Lemon Juice
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 2nd, 2015, 1:19 pm

Thanks, I didn't find it before. I'll give it a try when I get more time to play with it.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Philip Chee

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted February 6th, 2015, 7:04 am

Lemon Juice wrote: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
Last edited by Philip Chee on February 6th, 2015, 7:17 am, edited 1 time in total.

Philip Chee

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted February 6th, 2015, 7:13 am

Lemon Juice wrote: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

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted February 6th, 2015, 7:16 am

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
 
Posts: 784
Joined: June 1st, 2006, 9:41 am

Post Posted February 8th, 2015, 4:10 pm

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...
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Return to Third Party/Unofficial Builds


Who is online

Users browsing this forum: No registered users and 2 guests