Closed
Bug 14932
Opened 25 years ago
Closed 25 years ago
Mozilla asserts if compiled --disable-client-wallet
Categories
(Toolkit :: Form Manager, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: cls, Unassigned)
References
Details
First, you need to apply this patch to get it to compile: RCS file: /cvsroot/mozilla/xpfe/browser/src/nsBrowserInstance.cpp,v retrieving revision 1.19 diff -u -r1.19 nsBrowserInstance.cpp --- nsBrowserInstance.cpp 1999/09/23 17:46:03 1.19 +++ nsBrowserInstance.cpp 1999/09/26 06:25:31 @@ -78,9 +78,9 @@ #include "nsIDocumentLoader.h" #include "nsIObserverService.h" #include "nsFileLocations.h" +#include "nsIFileLocator.h" #ifdef ClientWallet -#include "nsIFileLocator.h" #include "nsIFileSpec.h" #include "nsIWalletService.h" static NS_DEFINE_IID(kIWalletServiceIID, NS_IWALLETSERVICE_IID); Here's the script output: cls@amadeus:bin> ./mozilla-apprunner.sh MOZILLA_FIVE_HOME=/opt/cls/obj/dist/bin LD_LIBRARY_PATH=/opt/cls/obj/dist/bin MOZ_PROGRAM=./apprunner MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsNativeComponentLoader: autoregistering /opt/cls/obj/dist/bin/components nsNativeComponentLoader: autoregistering succeeded nsUnixToolkitService: Using 'gtk' for the Toolkit. NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so, GFX_DLL=libgfx_gtk.so started appcores GFX: dpi=100 t2p=0.0694444 p2t=14.4 depth=16 Using '/opt/cls/obj/dist/bin' as the resource: base initialized appshell Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End ProfileName : cls ProfileDir : /home/cls/.mozilla/cls Profile Manager : Profile Wizard and Manager activites : End PreCondition: "dup release" (0 != mRefCnt) at file /opt/cls/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 155 Break: at file /opt/cls/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 155 cls@amadeus:bin>
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Comment 1•25 years ago
|
||
You must have an old tree. That fix was made on September 18. It is revision 1.17 of nsBrowserInstance.cpp.
I updated my tree on the evening of Sep 25 and the version of nsBrowserInstance.cpp is 1.19 (as the patch shows). Which problem were you referring to as fixed....the compile time problem or the runtime problem?
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Updated•25 years ago
|
Resolution: INVALID → ---
Target Milestone: M14
Comment 4•25 years ago
|
||
I was referring to the compile-time problem. But I see what the problem is. Previously I moved nsFileLocations.h outside of the ifdef. Now you are saying that I also need to move nsIFileLocators.h outside. I misread it and thought you were referring to the file I previously moved. Sorry. As far as the runtime problem, I don't understand what your output is saying. Can you describe the problem in words? Thanks.
Mozilla asserts at line 155 of nsAppShellService.cpp which I've pasted below: NS_IMPL_ISUPPORTS(nsAppShellService, kIAppShellServiceIID); From there, I'm a bit lost as it descends into macro hell and I'm not familiar with the entire xpcom setup. Based upon the "dup release" message, I'm guessing that something is unconditionally trying to free a reference to the k*WalletService?ID . A cursory grep of the tree shows that xpfe/bootstrap/nsAppRunner.cpp has several references to k*WalletService?ID that are not ifdef'd but I have no idea if they are part of the problem.
Updated•25 years ago
|
Target Milestone: M14 → M11
Comment 6•25 years ago
|
||
On giving some more thought to this, I'm going punt on this. Here's why. The ifdefs and conditional compilation that were put in for ClientWallet were done so just for the landing. In case the landing failed, I would be able to quickly disable it rather than having to back out the changes from every file that I touched. Now that it is landed, the ifdef should never be turned off. As far as modularity goes, ClientWallet is not a problem. If you don't want to use it, simply remove its dll from the components directory. That should work -- if it doesn't then that's a serious bug and I will fix it. As far as precedence goes, consider necko. I'll wager you that we will fail miserably if we ever tried to build today with necko turned off. So what I will do is remove the few remaining vestiges of ifdef ClientWallet (in nsBrowserWindow.cpp and nsBrowserInstance.cpp). Then I'll mark this bug as fixed.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 7•25 years ago
|
||
I removed the ifdefs from nsBrowserInstance since that is the one that affect the mozilla build. Marking bug as fixed.
Ok, that still doesn't resolve the problem of the "broken" configure option but I'll just remove the option. The situation is hardly comparable to the necko case as necko was completely replacing another essential piece of Mozilla whereas the wallet is just an added extension. Speaking of which, since the wallet is an extension, shouldn't the building of it be controlled by the --enable-extensions flag?
Comment 9•25 years ago
|
||
I have no idea what the enable-extensions flag is or how it is used.
Reporter | ||
Comment 10•25 years ago
|
||
--enable-extensions is a configure option that allows builders to turn on (or off) certain extensions to mozilla, like rginda's irc extension. Unfortunately, this is not going to work for client-wallet. If the extensions/wallet directory doesn't exist in the tree (or to be more accurate, nsIWalletService.h isn't exported to $DIST), then the tree will not build. If client wallet is truly an extension, then Mozilla should be able to build with that tree missing/not being traversed. If it's not an extension, then it shouldn't be in the extensions directory.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Assignee: morse → nobody
Product: Core → Toolkit
QA Contact: paulmac → form.manager
Target Milestone: M11 → ---
Version: Trunk → unspecified
You need to log in
before you can comment on or make changes to this bug.
Description
•