Closed Bug 394502 Opened 17 years ago Closed 14 years ago

make SeaMonkey build with libxul

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kairo, Assigned: standard8)

References

Details

Attachments

(1 file, 10 obsolete files)

39.92 KB, patch
Details | Diff | Splinter Review
We want to get at a stage where we can build SeaMonkey with libxul like Firefox already does.
For this, we need to get rid of using non-frozen linkage, from what I know.

This bug acts as a tracker until it makes sense to do the real switchover, which can also happen here. Adding several bugs that I know or think are currently prohibiting this.
No longer blocks: 377319, 381157, 389070, 390025
Depends on: 377319, 381157, 389070, 390025
We also need places as toolkit/library requires all components that can normally be built in toolkit/components to be built... (unless we find an interesting way of doing ifdefs ;-) )
Depends on: 382187
Depends on: 397277
I don't know if this will be useful in the future for anyone who works on this, however, as I've done it, I may as well document it just in case.

To build a reduced version of SeaMonkey with --enable-libxul, apply the patch I'm attaching now, and the one from bug 397277 (unless that is already fixed, of course). Then in your .mozconfig add the lines:

# for libxul
ac_add_options --enable-libxul
ac_add_options --disable-mailnews
ac_add_options --enable-places
ac_add_options --enable-extensions=default,-wallet,-typeaheadfind

All the disable/enables here are covered by dependent bugs. The patch may not be the correct/complete fix - I'm fairly sure that the ldap xpcom sdk won't be compiled into libxul currently.

The autocomplete changes would probably also be dependent on bug 263042 being fixed, but may be acceptable as a short term get us running on libxul fix.

Note: the libxul that this produces won't be the same as xulrunner/firefox due mainly to the differences in xpfe/components/
No comments in more than seven months. Robert, Mark, is this bug still relevant (and not yet fixed) for Sm-trunk = suiterunner?
(In reply to comment #3)
> No comments in more than seven months. Robert, Mark, is this bug still relevant
> (and not yet fixed) for Sm-trunk = suiterunner?
> 
Oh, look, there's 5 open bugs that block this one, I wonder why this hasn't had any activity.
Depends on: 450781
Depends on: mailnews-libxul
No longer depends on: 377319
QA Contact: build-config → build-config
Depends on: 531292
Depends on: 534689
Blocks: SM-OOPP
Blocks: 534689
No longer depends on: 534689
Blocks: 588067
This was originally written by ted in bug 562313 for Firefox.  It got the stamps it needs to land there, though I made some minor changes.

This provides a hook to insert arbitrary static libs and components into libxul and arbitrary directories into tier_platform.
This uses the previously provided hooks to insert mailnews, etc into libxul.  With this patch I can build a seemingly working Seamonkey build if I disable LDAP.  LDAP is hard because of its antiquated build system.
To expand slightly on the last, if we can convince the pure c parts of LDAP to form a static lib it should be easy.  Alternatively we could probably link LDAP's shared libs to libxul, that would be slightly messier, but it should be doable.
The build is a little crashy, not sure if that's from LDAP missing or something with the patches.
(In reply to comment #5)
> This was originally written by ted in bug 562313 for Firefox.

Interesting !
(Though I noticed bug 562313 comment 12 ... but which seems to solve that bug issue only.)

Iiuc, these 2 patches might help people working on c-c libxul bugs, and maybe Thunderbird (Bug 306324 comment 10),
but may not be what SeaMonkey would want w.r.t. bug 451923 (as it stands).

(In reply to comment #6)
> LDAP is hard because of its antiquated build system.

Good news is bug 590494 (work) :-)
(In reply to comment #9)
> but may not be what SeaMonkey would want w.r.t. bug 451923 (as it stands).

Building on top of XULRunner is not an important goal right now, while building with libxul enabled in some way is, so just ignore that other bug for the moment while we're working on this one here.
Depends on: 593355
Updated and slightly simplified core patch. Still needs something to deal with LDAP.
Assignee: nobody → bugzilla
Attachment #282033 - Attachment is obsolete: true
Attachment #471383 - Attachment is obsolete: true
Attachment #471384 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attached patch comm-central changes (obsolete) — Splinter Review
This is WIP comm-central changes, mainly been focussing on mailnews and Thunderbird though with this patch. Still to address:

- LDAP
- Are we packaging everything that we should be.
- Sync suite/ changes with mail/ changes.
- Sort out if it is sensible to export symbols to let the two imap cpp tests to build.
- Simplify build and make sure we're not too broken for the --disable-libxul or libxul + separate mailnews libs configurations.

I have a build on try server with the current versions of these two patches. I believe Thunderbird builds and mainly works with these patches, but that'll confirm it and hopefully we'll get some mozmill runs if the packaging is not too wrong.
Comment on attachment 472184 [details] [diff] [review]
comm-central changes

>diff --git a/bridge/bridge.mk b/bridge/bridge.mk
>+ifdef MOZ_CALENDAR
>+APP_LIBXUL_DIRS += $(DEPTH)$(SUBDIR)/calendar/lightning
>+endif

Why need calendar here? Lightning should completely be an add-on and not linked into libxul, at least not at this moment.


>diff --git a/bridge/confvars.sh b/bridge/confvars.sh

I'm not yet sure why this file is needed at all and why those very are not just set in the app-specific confvars.sh files, but...

>+MOZ_APP_COMPONENT_LIBS="mail msgsmime import"
>+MOZ_APP_COMPONENT_INCLUDE="MODULE(xpAutoComplete) MODULE(nsMailModule) MODULE(nsMsgSMIMEModule) MODULE(nsImportServiceModule)"

...including mail/-specific stuff here won't work for suite.

>diff --git a/mail/build.mk b/mail/build.mk
>-tier_app_dirs += xpfe/components/autocomplete
>-

Is this directly related? You don't need this version any more? If so, how does suite need to deal with that (we need at least the XBL from there)?

>-ifdef MOZ_CALENDAR
>-tier_app_dirs += calendar/lightning
>-endif

I'd think this should stay here (see above).

> tier_app_dirs += \
> 	mail \
>+	editor/ui \
> 	$(NULL)

So you can't undef MOZ_COMPOSER any more? Should this really be a part of this bug?

>diff --git a/mail/confvars.sh b/mail/confvars.sh
>+MOZ_APP_COMPONENT_LIBS="mail msgsmime import xpautocomplete mailcomps"
>+MOZ_APP_COMPONENT_INCLUDE=nsMailComponents.h

Hmm, you're inconsistent about those. Here you define them directly (which I think i prefer), for suite you include the bridge/ version.

>diff --git a/mail/installer/package-manifest.in b/mail/installer/package-manifest.in

You'll probably be able to clean this up, and will need to add some stuff to removed-files, but that can be dealt with once everything builds and runs.

>diff --git a/suite/build.mk b/suite/build.mk
>-tier_app_dirs += xpfe/components/autocomplete
>-

Umm, that takes away the autocomplete XBL we depend on in urlbar autocomplete, AFAIK. It should work with the binary code from toolkit, if LDAP does, but the XBL is probably needed on our side, so we need to copy that over to comm-central and include it from there (which has been our plan for some time for the point that LDAP autocomplete works with the toolkit impl).

>-ifdef MOZ_COMPOSER
>-tier_app_dirs += editor/ui
>-endif

Umm, I don't think you can just take that away from us completely!

>-tier_app_dirs += $(MOZ_BRANDING_DIRECTORY)

Umm, what about that one?

>-ifdef MOZ_CALENDAR
>-tier_app_dirs += calendar/lightning
>-endif

See above.

>diff --git a/suite/confvars.sh b/suite/confvars.sh
>+MOZ_IPC=

No, we want to kill this line as soon as we're building libxul. We only disable it because it breaks without libxul.

>+if [ "$COMM_BUILD" ]; then
>+    source ${_topsrcdir}/bridge/confvars.sh
>+else
>+    source ${_topsrcdir}/../bridge/confvars.sh
>+fi

See above, we shouldn't be inconsistent with mail/confvars.sh in this one.
(In reply to comment #13)
> >+MOZ_APP_COMPONENT_LIBS="mail msgsmime import"
> >+MOZ_APP_COMPONENT_INCLUDE="MODULE(xpAutoComplete) MODULE(nsMailModule) MODULE(nsMsgSMIMEModule) MODULE(nsImportServiceModule)"
> 
> ...including mail/-specific stuff here won't work for suite.

Oh, wait, this "mail" is actually the mailnews "library", nothing mail/-specific.
As I tried to imply in comment 12 this isn't review-ready yet. So I'm not going to respond to the comments especially as you've missed the one about me still needing to sync suite to mail.

However thanks for the comments, as they have pointed out a few things that I can fix.
(In reply to comment #15)
> However thanks for the comments, as they have pointed out a few things that I
> can fix.

That was all I intended, actually, I just tried to point out everything I saw so you can address those before requesting a formal review. :)
Still not ready but moved on a bit:

- Supports building of LDAP libraries, and including the xpcom part of those in libxul.
- Attempts to sync suite/ changes with the mail/ changes, though these aren't tested.

Current issues:

- Shared builds are currently broken - this needs an additional switch somewhere. I want to support for now until we get the quicker linking on mac at least.
- Can't disable LDAP with this patch.
Attachment #472181 - Attachment is obsolete: true
Attachment #472184 - Attachment is obsolete: true
Depends on: 597465
Updated patch. Outstanding issues:

- I think --disable-ldap may be broken, but there again it may work if you don't mind it building the ldap components anyway. I'm tempted to leave it like this for now, as the UI when disabled is not good anyway.
- Windows builds fail with export/import error. I think this just needs some extra tweaks to what I've done in msgCore.h, just not had time to investigate yet.
- suite/ stuff is just copied not tested. I suspect a lot of what may need to be done there is to make it compile with internal API, or keep it external API (I can't remember which it is at the mo).
- Still testing the packaging changes for mail/.

This patch also adds back in support for fully shared builds, and removes the option for static builds.

I think the fully shared builds option breaks building in "classic" libxul style, but I'm thinking that we can get this going again once we've got some libxul support into the tree.
Attachment #473192 - Attachment is obsolete: true
Would the export/import issues be covered by either of bug 582195 or bug 591098?
(In reply to comment #19)
> Would the export/import issues be covered by either of bug 582195 or bug
> 591098?

No. Like I said, I'm pretty sure its the tweaks in msgCore.h, and I'm also fairly sure it'll be simple to solve when I next sit down and think about it for a few minutes.
(I now have something on try to test a fix for it).
I've now fixed the Thunderbird windows builds, although its reminded me that we won't have the 3 c++ unit tests for mailnews for now, and we'll probably break binary extensions to begin with (expect we'll need to export functions - but we can use this as an opportunity to determine which ones are actually needed).

I've fixed one issue with the suite/ set-up, I currently have builds re-running to see how far it gets now.
Attached patch Possible Fix (obsolete) — Splinter Review
I believe this should now work for libxul and shared configurations of Thunderbird and libxul configuration of SeaMonkey - I've got the SeaMonkey configuration running on try. I've not tested the shared configuration yet, I also need to figure out the correct packaging changes (try has no package-compare at the moment, I've got a request in to get it back).

It needs the patch on bug 597465 applied to mozilla/ to work.

Note that this patch keeps suite's compiled code in suite/ outside of libxul - it has already been converted to external API and it was easier to do that separately than to put in conditionals for switching back to internal API (this could be done later if desired, but for now gets us going). SeaMonkey's mailnews and related libraries will still be linked inside of libxul with this patch.
Attachment #476332 - Attachment is obsolete: true
Attached patch The fix (obsolete) — Splinter Review
This one updates the packaging files so that we hopefully get everything in place for being able to land this.

Note that SeaMonkey will need further clean-ups to its packaging files, but I've agreed with Robert that this can be done afterwards. The current changes for the SM packaging files should be enough that SM will run correctly after landing the patches.

I think I've tested this as far as I sensibly can, time to get it out for review and (hopefully) landing. Requesting review from Justin and Robert, I'll take whichever comes first ;-)
Attachment #476561 - Attachment is obsolete: true
Attachment #476776 - Flags: review?(kairo)
Attachment #476776 - Flags: review?(bugspam.Callek)
Comment on attachment 476776 [details] [diff] [review]
The fix

Just some drive-by nits for now:

>+++ b/mail/components/build/nsMailComponents.h
>+++ b/suite/components/nsSuiteComponents.h

To avoid the "SHOOT US IN THE FOOT" feeling can you at least add a comment about needing to sync shared stuff between these two apps? (I was tempted to ask for a shared header, but then I remembered all the places that would also need updating too)

>diff --git a/configure.in b/configure.in
>+dnl XXX Temporarily disabled for now until we have finialised how we'll link
>+dnl with libxul in the future.
>+dnl MOZ_ARG_ENABLE_BOOL(static,
>+dnl [  --enable-static         Enable building of internal static libs],
>+dnl    BUILD_STATIC_LIBS=1,
>+dnl    BUILD_STATIC_LIBS=)

I'd much rather we stuff |MOZ_STATIC_BUILD_UNSUPPORTED| into our app-config.mk's rather than commenting out all this. Unless we truely do want to remove it.

a/mailnews/base/test/TestMsgStripRE.cpp

Why this files change (include nsMemory) when we don't even build it if we enableLibxul and thats all this patch does?

mailnews/imap/test/Makefile.in

nite: wrap it in ONLY ONE ifndef instead of splitting it, and use the same comment as the mailnews/base/test case.



Ok all that said, this looks relatively good. I want to test it before I officially stamp it, and I am ok with SeaMonkey deferring packaging changes until after this lands, please file a bug, and beware of packaging bitrot with Bug 575894
Attachment #476776 - Flags: feedback+
Comment on attachment 476776 [details] [diff] [review]
The fix

>diff --git a/configure.in b/configure.in
>+dnl XXX Temporarily disabled for now until we have finialised how we'll link
>+dnl with libxul in the future.
>+dnl MOZ_ARG_ENABLE_BOOL(static,
>+dnl [  --enable-static         Enable building of internal static libs],
>+dnl    BUILD_STATIC_LIBS=1,
>+dnl    BUILD_STATIC_LIBS=)
> 
> [...]
> 
>-if test -n "$MOZ_STATIC_BUILD_UNSUPPORTED" -a -n "$BUILD_STATIC_LIBS"; then
>-	AC_MSG_ERROR([--enable-static is not supported for building $MOZ_APP_NAME. You probably want --enable-libxul.])
>-fi
>-
>-if test -n "$MOZ_ENABLE_LIBXUL" -a -n "$BUILD_STATIC_LIBS"; then
>-	AC_MSG_ERROR([--enable-libxul is not compatible with --enable-static])
>-fi

I don't agree with that. For now, we should set MOZ_STATIC_BUILD_UNSUPPORTED and leave those as they are, erroring out with it. We still can go back and changhe that in a patch that enables static libxul if that ever comes along. Until then, we really should error out with static though.


>diff --git a/mail/Makefile.in b/mail/Makefile.in
>+ifndef MOZ_ENABLE_LIBXUL
>+DIRS += components
>+endif

Please add a comment why this is only built (here) for non-libxul and where it's invoked else.

>+ifndef MOZ_ENABLE_LIBXUL
> ifndef MOZ_INCOMPLETE_EXTERNAL_LINKAGE

This reminds me, from where we are, should we file a followup to rename MOZ_INCOMPLETE_EXTERNAL_LINKAGE to something more sensical?

>diff --git a/mailnews/base/test/TestMsgStripRE.cpp b/mailnews/base/test/TestMsgStripRE.cpp

As Callek said, you are excluding this anyhow here, so no need to patch it, let's move that into a followup for making those tests work again.

>diff --git a/suite/confvars.sh b/suite/confvars.sh
>+MOZ_IPC=

I need to do another build to verifiy it builds and works with the browser side, but unless I say otherwise, please leave out this one. The only reason why have this disabled is because we are not building libxul right now. If you don't feel goo with this, then at least please leave the comment before it in there and we'll remove both according to that bug mentioned there, then.

>diff --git a/suite/installer/package-manifest.in b/suite/installer/package-manifest.in
>diff --git a/suite/installer/removed-files.in b/suite/installer/removed-files.in

Yes, we'll need a followup to deal with those more. Adding mozz to removed-files is probably overdoing it, as we probably don't have shared builds to update from anyhow. But then, this can all be dealt with in a followup.


In fast testing, both dist/bin and dist/seamonkey (i.e. post-packaging) builds work fine on Linux32 in a default profile for opening any windows, but unfortunately, once I created a mail profile (i.e. immediately after the wizard, when the account is being used the first time), it crashes. Same with existing profiles that already have accounts, just that here it's on browser startup, when we invoke biff for the account. I don't have symbols on that build, so can't tell more right now, but can possibly look into that tomorrow.

I'm bold and give this an r+ despite this, on the premise of addressing the comments above and with the hope of finding the crash before the checkin. Still, I'd rather have a round of builds with crash reports than no Windows nightlies, so I'm in favor of pushing hard to get this in.
Attachment #476776 - Flags: review?(kairo) → review+
(In reply to comment #26)
> >+ifndef MOZ_ENABLE_LIBXUL
> > ifndef MOZ_INCOMPLETE_EXTERNAL_LINKAGE
> 
> This reminds me, from where we are, should we file a followup to rename
> MOZ_INCOMPLETE_EXTERNAL_LINKAGE to something more sensical?

IMO its still incomplete. The follow-up we should have is for enabling "proper" libxul builds to work.

> >diff --git a/suite/confvars.sh b/suite/confvars.sh
> >+MOZ_IPC=
> 
> I need to do another build to verifiy it builds and works with the browser
> side, but unless I say otherwise, please leave out this one.

I wanted to do one step at a time, so that if there are problems, we're not looking through too many issues - doing it this way also means you can create at least one nightly between the two to have as comparison.
Attached patch The fix v2 (obsolete) — Splinter Review
This patch addresses the review comments and also moves jsd/jsd3250 from the packaged files to the removed files. It probably wouldn't hurt, but just in case, I didn't want to leave the old libraries hanging around.
Attachment #476776 - Attachment is obsolete: true
Attachment #476776 - Flags: review?(bugspam.Callek)
This one is better, in that it covers all the review comments I meant to cover.
Attachment #477270 - Attachment is obsolete: true
Here's a stack trace of the crash I'm seeing:

Program received signal SIGSEGV, Segmentation fault.
0xb759152d in nsMsgDatabase::GetDBFolderInfo (this=0xacea12f0, result=0xbfffc2f4) at /mnt/mozilla/hg/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1450
(gdb) bt
#0  0xb759152d in nsMsgDatabase::GetDBFolderInfo (this=0xacea12f0, result=0xbfffc2f4) at /mnt/mozilla/hg/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1450
#1  0xb75b698c in nsImapMailFolder::GetDBFolderInfoAndDB (this=0xac3ddc00, folderInfo=0xbfffc2f4, db=0xbfffc2f0) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:2132
#2  0xb7499c7b in nsMsgDBFolder::ReadDBFolderInfo (this=0xac3ddc00, force=1) at /mnt/mozilla/hg/comm-central/mailnews/base/util/nsMsgDBFolder.cpp:661
#3  0xb7495537 in nsMsgDBFolder::UpdateSummaryTotals (this=0xac3ddc00, force=1) at /mnt/mozilla/hg/comm-central/mailnews/base/util/nsMsgDBFolder.cpp:3986
#4  0xb75b66b6 in nsImapMailFolder::UpdateSummaryTotals (this=0xac3ddc00, force=1) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:1817
#5  0xb75bb2b8 in nsImapMailFolder::GetDatabase (this=0xac3ddc00) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:663
#6  0xb75b695d in nsImapMailFolder::GetDBFolderInfoAndDB (this=0xac3ddc00, folderInfo=0xbfffc524, db=0xbfffc520) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:2126
#7  0xb7499c7b in nsMsgDBFolder::ReadDBFolderInfo (this=0xac3ddc00, force=0) at /mnt/mozilla/hg/comm-central/mailnews/base/util/nsMsgDBFolder.cpp:661
#8  0xb7494dd3 in nsMsgDBFolder::GetFlags (this=0xac3ddc00, _retval=0xbfffc6c4) at /mnt/mozilla/hg/comm-central/mailnews/base/util/nsMsgDBFolder.cpp:1237
#9  0xb75b9681 in nsImapMailFolder::AddSubfolderWithPath (this=0xafab3c00, name=..., dbPath=0xab819700, child=0xbfffc974, brandNew=0) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:431
#10 0xb75babda in nsImapMailFolder::CreateSubFolders (this=0xafab3c00, path=0xab819480) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:570
#11 0xb75bae8a in nsImapMailFolder::GetSubFolders (this=0xbfffca88, aResult=0xb7495061) at /mnt/mozilla/hg/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:614
#12 0xbfffca88 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)



(In reply to comment #27)
> I wanted to do one step at a time, so that if there are problems, we're not
> looking through too many issues - doing it this way also means you can create
> at least one nightly between the two to have as comparison.

OK, I'm seeing that IPC work with SeaMonkey with your patch, but we need some packaging adjustment to make it work accurately (right now, plugin-container isn't packaged) so let's hand it off to a followup. I still don't even want a nightly shipping between landing this and IPC, though. :)
I took a look at the SeaMonkey crash this morning and as it crashed in similar places on my profile, but not only that it was crashing in the browser as well (probably due to the mail check being turned on), I decided that we're not quite ready to land the SM parts of this patch yet.

However, as I also want to verify the results of the builds for the Thunderbird parts, I have landed the mail/ and mailnews/ parts and updated Thunderbird's mozconfigs:

http://hg.mozilla.org/comm-central/rev/47de99b5e40a
http://hg.mozilla.org/build/buildbot-configs/rev/af3aee009254

Hopefully they will verify the try server and my local testing results. In the meantime I have rebuilds running to see if I can then resolve the SM crashing issue.
The "SeaMonkey crash" is fully in mailnews, my stack is from launching browser, so that confirms that it's the mail biff check that invokes it, and as I said before, I prefer getting builds with crash reports to having Windows broken completely. So why is the SeaMonkey part not in despite that, and why isn't there at least a SeaMonkey patch then? This could have been the worst news you could give me this morning, really.
(In reply to comment #32)
> So why is the SeaMonkey part not in despite that, and why isn't
> there at least a SeaMonkey patch then?

My testing with a pre existing profile (one that I've had around for ages) showed that even just starting the browser would crash, resulting in a potential DoS for nightly users. IMO that is far worse than a broken Windows nightly.
Nightly users know how to download a new one. Those 200-300 users are capable of that if necessary. Also, this landed later than our nightlies start, which means we at least would get better data on the crash from tests running. But now, I guess we are stuck with "it crashes but nobody cares because nobody sees it". And there couldn't be a worse thing to happen for our project. I wonder for what reason this even is a SeaMonkey bug here.
Blocks: 598546
(In reply to comment #34)
> But
> now, I guess we are stuck with "it crashes but nobody cares because nobody sees
> it".

Oh ok, so I'll just dump the build that took 2 hours and stop the hour of SM specific debug that I've done already shall I? (as I said I would do in comment 31).
I've now found the source of the SeaMonkey crasher - the mork factory/components are not being registered.

It turns out the ifdefs for the libxul library mean that if places is enabled, mork isn't registered.

Normally I'd do a core patch, however due to the state of their tree we're probably going to find it hard to push that in quick.

I think I can work around it with some of the new options that we have, I've put some changes in locally and I'm now rebuilding to see if they will get mork registered and SeaMonkey running properly.
(In reply to comment #35)
> Oh ok, so I'll just dump the build that took 2 hours and stop the hour of SM
> specific debug that I've done already shall I? (as I said I would do in comment
> 31).

Gah, sorry, I of course am blind and have not seen you telling us you are actually investigating this problem. I guess I am too used to people leaving us in the cold that I don't expect someone helping any more. Sorry again.

(In reply to comment #36)
> I've now found the source of the SeaMonkey crasher - the mork
> factory/components are not being registered.

Interesting. Why does this only affect SeaMonkey, I thought Thunderbird uses the same mork?
(In reply to comment #37)

> Gah, sorry, I of course am blind and have not seen you telling us you are
> actually investigating this problem. I guess I am too used to people leaving us
> in the cold that I don't expect someone helping any more. Sorry again.

(Yes, please do calm down. Afaict, Mark is doing a wonderful job here and at least the "Core" parts of his patches haven't regressed anything (I hope) on the SeaMonkey side ... which is at least somehow good to check/know as a 1st step.
Also, I would support enabling SM MOZ_IPC as a 3rd step only, but I won't argue.)

> Interesting. Why does this only affect SeaMonkey, I thought Thunderbird uses
> the same mork?

Let me try to guess:
{
http://mxr.mozilla.org/comm-central/find?text=&string=%2Fconfvars.sh

http://mxr.mozilla.org/comm-central/source/mail/confvars.sh
53 MOZ_PLACES=
54 MOZ_MORKREADER=
55 MOZ_MORK=1

http://mxr.mozilla.org/comm-central/source/suite/confvars.sh
56 MOZ_MORK=1
}
So iiuc TB does use the same Mork, but doesn't use Places.
(In reply to comment #37)
> (In reply to comment #35)
> > Oh ok, so I'll just dump the build that took 2 hours and stop the hour of SM
> > specific debug that I've done already shall I? (as I said I would do in comment
> > 31).
> 
> Gah, sorry, I of course am blind and have not seen you telling us you are
> actually investigating this problem. I guess I am too used to people leaving us
> in the cold that I don't expect someone helping any more. Sorry again.

Accepted.

> (In reply to comment #36)
> > I've now found the source of the SeaMonkey crasher - the mork
> > factory/components are not being registered.
> 
> Interesting. Why does this only affect SeaMonkey, I thought Thunderbird uses
> the same mork?

There's an incorrect assumption in the libxul code that having places turned on means you don't want mork. See bug 598613 for the better details. For now I've worked around it by specifying the missing declarations in MOZ_APP_COMPONENT_LIBS and in nsSuiteComponents.h (with comments), so we don't need another core change - we can get that bug fixed when we can and then remove them later.
SeaMonkey patch now landed with the crash fixups and mozconfig changes:

http://hg.mozilla.org/comm-central/rev/3c34cdb6938b
http://hg.mozilla.org/build/buildbot-configs/rev/f97808979395

A few fixups also landed for Thunderbird:

http://hg.mozilla.org/comm-central/rev/6740532dfccb (fixing timeouts on bloat/mozmill tests)
http://hg.mozilla.org/comm-central/rev/8388db079b3f (fixing Linux bustage)

Current indications from the Thunderbird tree are looking good - I believe the current bustage should now resolve itself, but the builds are mainly clobbers so they may be slow for a while.
(In reply to comment #39)
> There's an incorrect assumption in the libxul code that having places turned on
> means you don't want mork.

"nice". Thanks for finding this.

(In reply to comment #40)
> SeaMonkey patch now landed with the crash fixups and mozconfig changes:

Ah, cool, I already thought I need to prepare the mozconfig changes as well. :)

I'm currently looking into clobbering all the builds, tracking that in bug 598546. Next step will be to figure out packaging and IPC.
Blocks: 598644
No longer depends on: mailnews-libxul
Blocks: 598646
Attachment #477280 - Attachment description: The fix v2a → The fix v2a [Checked in: See comment 31+40]
I believe I've now filed all the follow-up bugs. From the indications on tinderbox this bug should now be fixed.

Please file any follow-ups in separate bugs.

Thunderbird tree will remain closed overnight as I want to let the tree stabilise a bit and track what intermittent oranges/bustages we have (I think they are the same, but just in case). I'll let Robert decide when to re-open SeaMonkey.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 599809
You need to log in before you can comment on or make changes to this bug.