CVS trunk as start of today 2003-07-12. Compile errors out with : nsExternalHelperAppService.cpp:91:31: nsToolkitCompsCID.h: No such file or directory in uriloader/exthandler. Linux RH 8.0. Used "make -f client.mk checkout clobber build_all". .mozconfig : export MOZ_PHOENIX=1 mk_add_options MOZ_PHOENIX=1 export MOZ_THUNDERBIRD=1 mk_add_options MOZ_THUNDERBIRD=1 ac_add_options --disable-installer ac_add_options --disable-activex ac_add_options --disable-activex-scripting ac_add_options --disable-profilesharing ac_add_options --enable-extensions=wallet ac_add_options --enable-necko-protocols=http,file,jar,viewsource,res,data ac_add_options --enable-image-decoders=png,gif,jpeg ac_add_options --disable-accessibility ac_add_options --with-extensions="default" ac_add_options --enable-xft ac_add_options --disable-bidi ac_add_options --disable-ldap ac_add_options --disable-postscript ac_add_options --disable-dtd-debug ac_add_options --disable-debug ac_add_options --disable-tests ac_add_options --disable-mailnews ac_add_options --disable-composer ac_add_options --disable-logging ac_add_options --enable-crypto ac_add_options --enable-optimize="-O2 -g -pipe -march=i686" ac_add_options --disable-jsd ac_add_options --disable-venkman mk_add_options --mcpu=i686 mk_add_options --march=i686
Assignee: mozbugs-build → bryner
Severity: blocker → major
Component: Build Config → build-config
Product: Browser → Firebird
QA Contact: granrose → asa
Version: Trunk → unspecified
Created attachment 127918 [details] [diff] [review] build fix The file doesn't even use nsToolkitCompsID.h - remove the include altogether
*** Bug 212909 has been marked as a duplicate of this bug. ***
So after a bit of leg...err...finger-work, I've come up with a hypothesis for a (really short) timeline. 1) Christian Biesinger fixes bug 124014 and makes links handled by an external application show up in history. He adds the line nsCOMPtr<nsIGlobalHistory> history(do_GetService(NS_GLOBALHISTORY_CONTRACTID)); which is the first time that NS_GLOBALHISTORY_CONTRACTID is used in nsExternalHelperAppService.cpp. He adds the #include "nsIGlobalHistory.h" to bring in the symbol. This is revision 1.192 of NSExternalHelperAppService.cpp 2) David Baron checks in revision 1.193, which adds the #include of nsToolkitCompsCID.h if Firebird is being built. According to the build comment, this fixes MOZ_PHOENIX bustage. This all happened on June 30th. There probably is a step missing, since nsIGlobalHistory.idl lives in the xpfe directory. So now the pill is worse than the original illness. With levon's patch, I can build the uriloader. Since I'm not qualified to give out "r="s, I'll give it a t=am2stewa for "tested and seems to work". (Oh, and Hardware -> All, since it happens on Sun/Solaris as well. (There really needs to be a OS: Unices option if OS is going to be relevant.))
Hardware: PC → All
Created attachment 127945 [details] [diff] [review] newer patch Some more build fixes !
Attachment #127918 - Attachment is obsolete: true
Just attached a newer patch with some other places where the build fails. It seems that nobody is interested in building firebird at the moment. Nobody on IRC, or the forums, or bugzilla, seems to care. Unfortunately I'm now stuck on : nsAppRunner.cpp:86:35: InstallCleanupDefines.h: No such file or directory nsAppRunner.cpp:87:31: nsISoftwareUpdate.h: No such file or directory ... gmake: Leaving directory `/home/moz/src/mozilla/toolkit/xre' xpinstall (where these files are from) is listed in xre's Makefile.in REQUIRES list Is there anybody out there ?
Severity: major → blocker
Summary: nsToolkitCompsCID.h: No such file or directory prevents build → nsToolkitCompsCID.h: No such file or directory (and numerous firebird build failures)
Doing a "make" in xpinstall fixed the last problem. I guess I could turn on xpinstall dir if MOZ_PHOENIX in the toplevel Makefile.in but that just feels like it's wrong to me... Continuing with the build ...
After more investigation (reasoning that there must be one root cause behind all these build failures), I've discovered bug 107302, which deals with breaking stuff into tiers. On July 15th, cls checked in a patch to create a tier_50, which currently contains tools/jprof, xpfe, themes, tools/leaky, tools/codesights, l10n, and toolkit. This means that the required headers from toolkit aren't installed when tier_9 (where all the good stuff lives) is built. So we may have to add some directories from toolkit to tier_9, kinda like lines 217-221 of mozilla/Makefile.in (which add some directories from xpfe). That way, their header files will be in dist/include when they're needed.
fyi, with the given patch, and the manual make in xpinstall, it finally built and worked fine. Cc'd cls in the hope somebody can resolve the tier problem properly and apply the rest of the patch.
Firbird forked a bunch of interfaces, some of which had CIDs in the IDL files, and moved the CIDs into nsToolkitCompsCID.h. We shouldn't be using two separate IDL files for the same interface in the build at different points, so both patches here look wrong. I suspect seawood's changes caused the xpfe versions of the interfaces to be used during part of the build process. It would be easiest to un-fork these files. Have there been changes other than moving the CIDs out of the IDL?
(The approach in comment 8 would be a sufficient workaround. When that's done, though, we also should make the additions to tier_9 that weren't in Firebird before |ifndef MOZ_PHOENIX|.
Created attachment 127989 [details] [diff] [review] Changes to Makefile.in to get Firebird to compile Doesn't touch any file but Makefile.in. Since I made my changes by trial-and-error, I'd definitely want other people to try this patch and report back. Oh, and it doesn't require the previous patch to be applied.
> The file doesn't even use nsToolkitCompsID.h - remove the include altogether I don't understand how this part of the patch can be wrong ? Why include an unused header ?
Thunderbird builds are also broken with bustage in mozilla\toolkit. Is this bustage related to what you are seeing in firebird? illa-config.h -Wp,-MD,.deps/nsAppRunner.pp /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp:86:35: InstallCleanupDefines.h: No such file or directory /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp:87:31: nsISoftwareUpdate.h: No such file or directory /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp: In function ` nsresult VerifyInstallation(int, char**)': /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp:980: error: ` CLEANUP_REGISTRY' undeclared (first use this function) /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp:980: error: (Each undeclared identifier is reported only once for each function it appears in.) /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp:989: error: ` CLEANUP_MESSAGE_FILENAME' undeclared (first use this function) /home/andre/devel/cvs/mozilla/toolkit/xre/nsAppRunner.cpp:993: error: ` CLEANUP_UTIL' undeclared (first use this function)
Mhhh... does it make sense to add the keyword "smoketest" (blocker) ? =:-)
> > The file doesn't even use nsToolkitCompsID.h - remove the include altogether > > I don't understand how this part of the patch can be wrong ? Why include > an unused header ? Because you're wrong that it's unused. It uses |NS_GLOBALHISTORY_CONTRACTID|.
Comment on attachment 127989 [details] [diff] [review] Changes to Makefile.in to get Firebird to compile >+# Common dirs No need for a comment saying something that's obvious from looking at the code. > tier_9_dirs += \ > xpfe/appshell \ >- xpfe/browser/public \ >- xpfe/components/history/public \ > xpfe/components/sidebar/public \ > xpfe/components/xremote/public \ >+ xpfe/browser/public \ >+ $(NULL) No need to move xpfe/browser/public -- it just makes the diff bigger. >+ifdef MOZ_XUL_APP >+tier_9_dirs += \ >+ toolkit/components/autocomplete \ >+ toolkit/components/history \ >+ toolkit/components/satchel \ >+ toolkit/components/build \ >+ browser/components/bookmarks \ >+ $(NULL) Why do you need autocomplete, satchel, and bookmarks? I'd think you'd only need history and build. >+else >+tier_9_dirs += \ >+ xpfe/components/history/public \ > $(NULL) >+endif
Scott: Sure looks like it. Version 1.222 of Makefile.in moved xpinstall from tier_9 to tier_90. I don't know why I didn't have to deal with that when I made my patch. It sure looks like toolkit uses the exports from xpinstall, thus it needs to be in the same tier. (i.e. my patch is incomplete) Anyone else for reverting version 1.222 until the different parts of Mozilla aren't tied so closely to each other? As for the smoketest blockingness of this bug, it blocks clobber .*bird builds. Is that good enough for smoketest?
David said: "Why do you need autocomplete, satchel, and bookmarks? I'd think you'd only need history and build." Please don't add that to MOZ_XUL_APP. Those should be MOZ_PHOENIX ifdef makefiles. MOZ_XUL_APP is for the suite of stand alone applications including firebird and thunderbird. Thunderbid does not use satchel, the new auto complete or bookmarks. Moving it into the ifdef makes it depend on those modules. That's what MOZ_PHOENIX is for. =) Good catch dbaron.
Oh, I see the problem. The build directory doesn't have a separate public directory, so this tries to put it in tier 9. That's a problem. We need to un-fork nsIGlobalHistory anyway, since it's frozen. I'll propose a patch shortly.
Created attachment 128024 [details] [diff] [review] patch This unforks the *contents* of nsIGlobalHistory and fixes the root Makefile.in. I didn't completely clobber, but I did clobber all the files that included nsToolkitCompsCID.h.
I also needed to make this change to mozilla/Makefile.in: ifdef MOZ_XUL_APP tier_50_dirs += toolkit +endif + +ifdef MOZ_PHOENIX +# xpfe/components/search depends on nsIBookmarksService.idl +tier_50_dirs += browser/components/bookmarks/public endif and also needed to add some additional missing makefiles to allmakefiles.sh.
Created attachment 128082 [details] [diff] [review] patch I already checked in the allmakefiles.sh changes, since they're obvious. Here's the rest of the patch for review.
Attachment #128024 - Attachment is obsolete: true
Comment on attachment 128082 [details] [diff] [review] patch r=mscott if you need it.
Attachment #128082 - Flags: review+
Fix checked in to trunk, 2003-07-19 14:19 -0700.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
building Firebird under Linux still breaks on my system, now in tier_90, with an invalid shell command line - out the top of my head /usr/bin/sh for d in ; XXXXX done; (with XXXX being some command) Empty for...loop. The last commit I had was this one http://bonsai.mozilla.org/cvsview2.cgi?subdir=mozilla/security/coreconf&files=Linux2.6.mk&command=DIRECTORY&branch=HEAD&root=/cvsroot
Here's the error message itself: --8<-- make: Leaving directory `/alfons/Projects/mozilla/xpinstall' make: Leaving directory `/alfons/Projects/mozilla' /usr/bin/make tier_90 make: Entering directory `/alfons/Projects/mozilla' tier_90: /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `set -e; for d in ; do /usr/bin/make -C $d export; done ; /usr/bin/perl ./config/purge-old-headers.pl ./dist/include ; for d in ; do /usr/bin/make -C $d libs; done' make: *** [tier_90] Error 2 make: Leaving directory `/alfons/Projects/mozilla' make: *** [default] Error 2 make: Leaving directory `/alfons/Projects/mozilla' make: *** [build] Error 2 -->8--
Created attachment 128088 [details] [diff] [review] possible patch Does this fix that error. This was the change I had to make that I was least happy about. However, I think the intent of toolkit/xre/ was really that it be something that applications should build on, so I didn't want to split that into tier_99, but maybe that's the better solution?
Comment on attachment 128024 [details] [diff] [review] patch clearing obsolete review request
yes, that fixes it. thanks.
Comment on attachment 128088 [details] [diff] [review] possible patch That's fugly. Just move xpinstall back into tier_50 unconditionally. We don't need different build paths for basic components based upon the app being built.
Attachment #128088 - Flags: review?(cls) → review-
Created attachment 128434 [details] [diff] [review] patch
Attachment #128088 - Attachment is obsolete: true
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.