223084 - enable the static component loader by default (for the GRE)

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GRE Core, defect)

Description

[Benjamin Smedberg]

I believe we should enable the static component loader by default when building
XPCOM. Firebird/etc would like to keep themselves as a static build, so enabling
the static component loader through the --enable-static configure flag causes
odd header/implementation dependencies.

My patch here adds a new configure flag --disable-static-component-loader in
case someone really doesn't want the loader for some reason.

Comment 1

[Benjamin Smedberg]

Attachment: configure switch --disable-static-component-loader

Comment 2

[Doug Turner (:dougt)]

Comment on attachment 133758 [details] [diff] [review]
configure switch --disable-static-component-loader

this should be okay.  When you land this, please post to the XPCOM newsgroup
regarding this change.

Comment 3

[Benjamin Smedberg]

Checked in.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This made the egg tinderbox (minimo static build) go orange:

http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Testerbox

(balsa, the other static build tinderbox, should be restarted shortly)

Comment 5

[Benjamin Smedberg]

I forgot to #include "xpcom-private.h" in nsComponentManager.h; this is now fixed.

Comment 6

[Ali Ebrahim]

The Firebird static builds process now compeletes successfully, but the
resulting MozillaFirebird.exe does not start. When I double click on the exe,
the process starts up for a second and then dies.

Comment 7

[Darin Fisher]

ok, this horked the static build because of this change:

-----------------------------------------------------------------------
 NS_IMETHODIMP
 nsStaticComponentLoader::AutoRegisterComponents(PRInt32 when, nsIFile *dir)
 {
     if (mAutoRegistered)
         return NS_OK;
 
+    if (dir)
+        return NS_OK;
+
     nsresult rv;
     if (NS_FAILED(rv = GetModuleInfo()))
         return rv;
 
     RegisterSelfData data = { mComponentMgr, dir };
 
     PL_DHashTableEnumerate(&mInfoHash, info_RegisterSelf, &data);
 
+    mAutoRegistered = PR_TRUE;
     return NS_OK;
 }
-----------------------------------------------------------------------

applying the following patch fixes the static build.

-----------------------------------------------------------------------
Index: nsStaticComponentLoader.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpcom/components/nsStaticComponentLoader.cpp,v
retrieving revision 3.11
diff -p -u -1 -0 -r3.11 nsStaticComponentLoader.cpp
--- nsStaticComponentLoader.cpp 30 Oct 2003 21:11:07 -0000      3.11
+++ nsStaticComponentLoader.cpp 3 Nov 2003 02:12:11 -0000
@@ -189,21 +189,21 @@ info_RegisterSelf(PLDHashTable *table, P
  
     return PL_DHASH_NEXT;
 }
  
 NS_IMETHODIMP
 nsStaticComponentLoader::AutoRegisterComponents(PRInt32 when, nsIFile *dir)
 {
     if (mAutoRegistered)
         return NS_OK;
  
-    if (dir)
+    if (!dir)
         return NS_OK;
  
     nsresult rv;
     if (NS_FAILED(rv = GetModuleInfo()))
         return rv;
  
     RegisterSelfData data = { mComponentMgr, dir };
  
     PL_DHashTableEnumerate(&mInfoHash, info_RegisterSelf, &data);
  
-----------------------------------------------------------------------

i guess no one ever tested the --disable-static-component-loader patch with an
actual static build :-(

Comment 8

[Darin Fisher]

correction:  that patch isn't necessary.  it isn't right either.  my tree was
out-of-date :(

sorry for the noise!!