Glue library is exporting symbols when it should not. In order to link to both xpcom and an embedding application, we must produce two versions of this library. One that exports all symbols which can be linked into xpcom. Another version which does not export symbols. This latter version can be linked into an embedding application. The set of symbols that an embedding application will require of xpcom proper will, at some point be dynamically looked up via the xpcom glue library. Until this time, the embedding applications will have to link to both. Changes: 1. All NS_EXPORT defines in xpcom/glue have been replaced with NS_COM. This is so that I can easily change what get exported. I could have modified NS_EXPORT, but we already have a NS_COM define. 2. Added some makefile foo which will create a static no-export version of the glue library. This will only occur with the make build system. (long live make!) 3. Factored out category manager utilities into a new header file. I want to do this because the nsICategoryManager if not frozen. Exposing this functionality to the glue library will cause problem when we change the nsICategoryManager. 4. Moved the inline operator method of nsCOMPtr_helper's into the class declaration. The problem is that if we left them as inline functions in the nsComponentManager.cpp, they would imported by code that referenced them. This causes an unsupportable dependency. 4a. Changed the nsCOMPtr_helper's based classes to use frozen component manager accessors. It use to use the static component manager class. 5. Fixed up the xpcom sample code to correctly build without any unsupported dependencies on XPCOM! Patch coming up.

Only has build on windows/gmake.

Comment on attachment 73773 [details] [diff] [review] Patch v.1 excellent! looks good I'd like to see r=cls just so we have build system coverage sr=alecf

These are the windows imports from the xpcom sample code. Note that the nspr requirement is because the sample uses a threadsafe version of nsISupports. bash-2.05$ dumpbin /imports nsTestSample.exe Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. Dump of file nsTestSample.exe File Type: EXECUTABLE IMAGE Section contains the following imports: xpcom.dll 402048 Import Address Table 402128 Import Name Table 0 time date stamp 0 Index of first forwarder reference 83A NS_GetMemoryManager 858 NS_ShutdownXPCOM 856 NS_RegisterXPCOMExitRoutine 83C NS_InitXPCOM2 MSVCRT.dll 402000 Import Address Table 4020E0 Import Name Table 0 time date stamp 0 Index of first forwarder reference 64 __p___initenv 58 __getmainargs B7 _controlfp 2B8 strcmp 29E printf 192 _purecall 297 memcpy D3 _exit 48 _XcptFilter 249 exit 6A __p__commode 10F _initterm 83 __setusermatherr 9D _adjust_fdiv CA _except_handler3 6F __p__fmode 81 __set_app_type Summary 1000 .data 1000 .rdata 1000 .text bash-2.05$ dumpbin /imports xpcomsample.dll Microsoft (R) COFF Binary File Dumper Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. Dump of file xpcomsample.dll File Type: DLL Section contains the following imports: xpcom.dll 10003048 Import Address Table 1000324C Import Name Table 0 time date stamp 0 Index of first forwarder reference 838 NS_GetComponentManager 83A NS_GetMemoryManager 856 NS_RegisterXPCOMExitRoutine nspr4.dll 1000303C Import Address Table 10003240 Import Name Table 0 time date stamp 0 Index of first forwarder reference 12 PR_AtomicDecrement 13 PR_AtomicIncrement MSVCRT.dll 10003008 Import Address Table 1000320C Import Name Table 0 time date stamp 0 Index of first forwarder reference 297 memcpy 192 _purecall 9D _adjust_fdiv 10 ??3@YAXPAX@Z 2BE strlen 29E printf F ??2@YAPAXI@Z 10F _initterm 291 malloc 2BA strcpy 299 memset 25E free KERNEL32.dll 10003000 Import Address Table 10003204 Import Name Table 0 time date stamp 0 Index of first forwarder reference 5D DisableThreadLibraryCalls Summary 1000 .data 1000 .rdata 1000 .reloc 2000 .text bash-2.05$

Comment on attachment 73773 [details] [diff] [review] Patch v.1 r=rpotts@netscape.com looks good... dougt is making sure that unix and the mac don't break !!

Comment on attachment 73773 [details] [diff] [review] Patch v.1 The change to xpcom/components/nsComponentManager.cpp llooks questionable. Did you mean for a big chunk of that file to only be available if MOZ_LOGGING is defined? If we turn that off via --disable-logging, is that going to break the build? The inline functions that it blocks off seem important. For the glue Makefiles, I'd prefer it if you used the same naming conventions that we use for zlib's objs.mk and its variables. For the standalone glue library, I'm not sure if we should use _s there. It conflicts with the use of _s to denote a sub-library in other Makefiles. (Yes, standalone zlib also appears to be broken in this regard.) I'd swap the names and make the one that actually links into libxpcom.so end with _s. I'm confused by the comment in xpcom/sample/Makefile.in. Will every user of xpcomglue have to explicitly disable the NS_COM export routines? You should be using EXTRA_DSO_LDOPTS instead of SHARED_LIBRARY_LIBS. Do we need to add xpcomglue to XPCOM_LIBS and MOZ_COMPONENT_LIBS ?

>The change to xpcom/components/nsComponentManager.cpp llooks questionable. Fixed. moved #endif up to line 69. >For the glue Makefiles, I'd prefer it if you used the same naming conventions that we use for zlib's objs.mk and its variables. Ick. I thought that that should change. "SRC_LCSRCS". Repeative. >I'd swap the names and make the one that actually links into libxpcom.so end with _s. Done. > I'm confused by the comment in xpcom/sample/Makefile.in. Will every user of xpcomglue have to explicitly disable the NS_COM export routines? Yeah. The code #include's a header that includes a class which uses NS_COM. (the nsComponentManagerUtils stuff). If the sample (and any client of this code) does not set this define, the class with be marked as imports, and be found in xpcom.dll. >You should be using EXTRA_DSO_LDOPTS instead of SHARED_LIBRARY_LIBS. Would not build that way... >Do we need to add xpcomglue to XPCOM_LIBS and MOZ_COMPONENT_LIBS ? Nope. Do you want a new patch?

Fixed cls's concerns.

Comment on attachment 73789 [details] [diff] [review] Patch v.2 carry over sr

>You should be using EXTRA_DSO_LDOPTS instead of SHARED_LIBRARY_LIBS. Chris, your right. How could I have had doubt. New patch coming up.

Compiles on linux.

>>For the glue Makefiles, I'd prefer it if you used the same naming conventions >>that we use for zlib's objs.mk and its variables. > Ick. I thought that that should change. "SRC_LCSRCS". Repeative. Actually, it's not. MODULES_ZLIB_SRC refers to the directory. _LCSRCS is the "local" (file only) list of C source files. _CSRCS is the list of sources with a relative or absolute (depends upon $(topsrcdir)) directory path.

if I change that, can I get your r=?

Comment on attachment 73824 [details] [diff] [review] patch v.3 Yep, sync the variables to the existing naming convention && r=cls

rolling in cls's comments.

Comment on attachment 73966 [details] [diff] [review] patch v.4 rolling in r/sr.

Why is the sample component losing nsXPIDLString.h and nsXPIDLCString? We use these samples as exemplars, and manual storage management is not exemplary. /be

This sample component can not depend on strings until a similar static-no-export build of strings is avaliable. If I did continue to use XPIDLCString, you would see dependencies against XPCOM. When someone changes one of these concrete classes, this component may stop working or worse.... I would much rather get the string libraries usable by component libraries seperately.

When will you have strings back in business, sample-wise? I think it's bad precedent to thrash the samples in a way that we cannot endorse. Is this all going to come together in a week or so? /be

>When will you have strings back in business, sample-wise? They were never in business!! They have always been unfriendly when it comes down to reuse in a component system. One change can bust any client. >I think it's bad precedent to thrash the samples in a way that we cannot endorse. Huh? It is perfectly acceptible to use a char* the way I am doing in the sample. I agree that the nsXPIDLString fu look nicer, but by contract, a |string| can be allocated into a char * buffer and freed by nsIMemory.Free. > Is this all going to come together in a week or so? I hope so, but probably not. I have not begun to look at this code. I hope to get some jag help, but we will see. If I do fail and we ship a mozilla 1.0 without this sting stuff in a static-no-export library, I do not want the sample application linking to xpcom to get it. We can ship a string lib post-moz1.

doug, you seem to be mixing up what is valid with what is recommended. It's valid for users to pass char * variables by their address to IDL-defined methods that have out string params/retvals. So what? We've had enough leaks that way, thank you. Did you miss my use of "exemplar"? >They were never in business!! They have always been unfriendly when it comes >down to reuse in a component system. One change can bust any client. This is nonsense. We freeze XPCOM interfaces, we can and are freezing string abstract interfaces. There is no difference other than what we choose. I'm not sure why you are talking about "reuse" and "component" as if they require XPCOM and manual storage management, but I don't buy it for a second. /be

LOL!!! I think that you are totally missing the point The point is nsXPIDLString is a concrete class and is *not* frozen. I can not recommended using concrete base classes to xpcom components if they want to run with many versions of mozilla. Do you follow? This is no nonsense, and you don't have to buy it - all you have to do is try it out. Build a component against a concrete class in xpcom, change the concrete class in xpcom, and see if you built component still works. Repeat as needed. Look - this patch is what jband, alec, rick, and I believe is the right thing to do. Time I am wasting explaining this to Mike and Brendan is wasting time that I could be spending working on critical Mozilla 1.0 build.

nsXPIDLString is a concrete class, which implements nsAString. So is nsCOMPtr_helper, which trades in XPCOM interface types. So is nsGenericModule, which implements nsIModule. You seem to recommend use of those latter "concrete base classes" (what inherits from nsXPIDLString?) for glue library consumers, unless I'm gravely mistaken. (I can't find anything that actually recommends what to use if you're linking with the glue library, so I'm reading the code to avoid another "duh", and ass-u-ming based on what you're putting in there.) Changes to nsCOMPtr_helper would break consumers. Solution: put a copy in the glue library, where it will never change after linking. Changes to nsGenericModule would break consumers. Solution: put a copy in the glue library, where it will never change after linking. Changes to nsXPIDLString would break consumers. Solution? I don't want to lead the witness, but I do notice that string is already a static library. I believe, though we should certainly check, that the AString interfaces are frozen. If you'd like, I can write an example of accessing them in C, so that you can see more clearly how they can be used in a component without access to a dynamically-linked copy of our specific string implementation. Or is your intent that people using the glue library can't use methods that involve the AString interface family in their parameters or return value? We have a _lot_ of those, including most of the DOM and URI methods.

so after all this, this is what I'm hearing: if our samples are going to use concrete classes from the string library, that they should be linking directly against string_s.lib. End of story?

Alec, your cutting out all of the wit. :-) I think the point that shaver is missing is that on most platforms, if you are linking to two or more libraries that share symbols, you are going to run into problems. This is the reason that I created the glue library which redefines NS_COM to mean nothing. This redefintion cause no symbols to be exported from that libray. Now, a component can link to both the "glue" library and xpcom. Something similar will have to happen if we want to have an xpcom component link to both "strings" and xpcom.

Gee, I should stop wasting time by fretting about samples recommending the worse pattern. Come on, Doug, this isn't about optimizing your time to checkin. /be

I am not sure how to take that. right not,using nsXPIDLString IS the worst pattern. You create an unsupportable component by requiring that this string class NEVER change else your component gets busted. Come on, Brendan, these samples are about reusable components without dependancies on unfrozen stuff.

> I think the point that shaver is missing is that on most platforms, if you are > linking to two or more libraries that share symbols, you are going to run into > problems. The point I'm missing isn't quite that, but is certainly related: why would a component need to link to both the glue library and the full XPCOM DSO? If everything you want is in libxpcom, because it includes the glue libraries wholesale -- the present case -- what do you need a separate glue lib linkage for? Possible answer: a component wishes to use our helper classes, but also needs access to some frozen interfaces within libxpcom.so. We don't want to guarantee the frozen binary form of the concrete helper classes, so we'd like them to copy those symbols in statically, rather than pulling them from libxpcom.so. (Is that what's meant by "in order to link to both xpcom and an embedding application" in the description? The idea of linking to an application confused me a fair bit, and I thought you were worried about two copies of the glue library, one from the component and one from the application.) Is this the scenario? If so, then it seems like _everything_ should link to both, and libxpcom shouldn't include the glue lib itself. But then we're back to the entire Mozilla application having to pay the inline-space tax and other performance penalties -- remember when you wanted to make nsGenericModule traverse a linked list instead of using a hash table, to avoid an NSPR linkage for those? Now you've got every nsCOMPtr_helper use going through our frozen accessors, when Mozilla already links to libxpcom and is more than willing to keep up with the unfrozen API in order to get that performance boost. I think we need a glue library that contains only self-contained helpers, which causes no libxpcom.so dependency, and which is used by component authors who want to reuse some of our useful helpers (nsCOMPtr, ns*String, nsGenericModule) but do not want a libxpcom linkage dependency. We may also need a library for people who want to use those helpers _and_ link to libxpcom for other (frozen, one hopes) entry points. If changes are required to make the helpers only depend on frozen/exported XPCOM interfaces, and those changes have performance effects that aren't desirable, then we need to fork those helpers. Adding a pile of function calls to every nsCOMPtr helper doesn't seem like something we want to impose on Mozilla-the-app cavalierly. (This may mean that we need a libxpcomstandalone.a and a different libxpcomhelper.a, perhaps. The changes that are on the table seem to approach the latter problem only, and I'm concerned about the effects on the application that come from not forking into a pure-vs-fast pair.)

dougt, sorry to be snappish, I was reacting poorly to other stuff not in this bug. I still am here to give all of us a hard time, though: 1. Frozen interfaces are not the only good here. We had way too many dumb leaks before nsCOMPtr and nsXPIDL*String. What's good for us is good for embedders, so I say samples should show nsXPIDLCString, with the necessary comments and build goop to link staticly with string. 2. We can andn do freeze concrete classes as well as abstract base classes. Why not freeze nsXPIDL*String? I'll go bug dbaron and jag. /be

Rick: the snapshot idea is a great one. Can we treat strings the same way?

> why would a component need to link to both the glue library and the full XPCOM DSO? A case and point is the nsMemory class. It is basically a wrapper for nsIMemory. The question is, How can I get the nsIMemory interface pointer? There has to be some API that xpcom proper exposes which the glue library can call to aquire this interface. This is the depend on the libxpcom. Now in a land far far away, the glue library will do a FindSymbol in the xpcom.so for these apis. That is our ultimate goal. For now, components that want to be protected against change of these classes will have to link a copy of this glue library in. Nothing is going to change with components that get rebuilt with xpcom. For example, cookies or mailnews - they are still going to link to just xpcom. They will not even know about glue. > If everything you want is in libxpcom, because it includes the glue libraries wholesale -- the present case -- what do you need a separate glue lib linkage for? Having a copy (or snapshop) of the glue library will allow the component to be protected against any changes in the xpcom shared library. Keep in mind that there is not a one to one matching of component and xpcom. A component should be able to exists in any mozilla runtime as so long as the componet only uses frozen APIS. >Possible answer: [snip] Is this the scenario? Yes. >I think we need a glue library that contains only self-contained helpers, which causes no libxpcom.so dependency, and which is used by component authors who want to reuse some of our useful helpers (nsCOMPtr, ns*String, nsGenericModule) but do not want a libxpcom linkage dependency. That would be nice. However, that would remove nsMemory, one of the most important classes. (see above for the depend reason) This patch is a step in the right direction and address the immediate requires of both mozilla 1.0, and embedding customers. We can provide different flavors of this "glue" library on demand post 1.0.

Mike, how does what I am doing differ from the snapshot idea?

Brendan, Ditto about the snappishness and all... > 1. Frozen interfaces are not the only good here. We had way too many dumb leaks before nsCOMPtr and nsXPIDL*String. What's good for us is good for embedders, so I say samples should show nsXPIDLCString, with the necessary comments and build goop to link staticly with string. If it is a condition of driver approval, I will get strings where they need to be.

This is how what we're currently doing differs from the snapshot idea: > If changes are required > to make the helpers only depend on frozen/exported XPCOM interfaces, and those > changes have performance effects that aren't desirable, then we need to fork > those helpers. We're not snapshotting and then purifying the snapshot. We're forcing the Mozilla-internal codepaths through the pure-and-frozen interfaces, at unmeasured performance cost (time and space). Maybe we can't avoid it, and we need to take the hit, but when I see people -- including yourself, dougt! -- bleeding from their fingers trying to claw back a 1% startup cost, I don't want to see us make that decision lightly.

>We're forcing the Mozilla-internal codepaths through the pure-and-frozen interfaces, at unmeasured performance cost (time and space). That is wrong. Take nsMemory as I sited above. not many folks are using that. There has been an effort underway to move memory allocations to malloc/new directly. I have not forced anyone to use the stuff we are moving into this "glue" library. I am just moving it so that we can take a snapshot and say to the component developer, "if it is good enough for us, it must be for you." >Maybe we can't avoid it, and we need to take the hit, but when I see people -- including yourself, dougt! -- bleeding from their fingers trying to claw back a 1% startup cost, I don't want to see us make that decision lightly. I hear you - performance has been an uphill battle in the rain with our supply lines cut. If these frozen pathes are expensive we should rethink how we do things. However, this is all without grounds - Are we slow because we are going through this glue code? I think that we need data before accusing something like this library of even showing up on the performance radar.

Comment on attachment 73966 [details] [diff] [review] patch v.4 need more changes to get strings working.

Okay. Here is what I am going to do: - make the string classes usable by embedding applications without having them have extra links to xpcom. I will update the sample code to use nsXPIDLStrings and stuff. - talk with scc about my changes to the helper classes to ensure that I am not doing something that we will regret. Mike and Brendan, what I need from you both is a detailed list of problems with the last patch. Thanks.

Includes scc@mozilla.org comments: Moves nsCOMPtr_helper derived operator() methods to be compiled in glue so that they can be shared in different complication units. Includes brendan@mozilla.org comments: Reverts nsXPIDLCString->char* converstion in sample code.

Shaver's in vacation this week -- he says if scc and I like it, it's good to go. I'll review in a sec. /be

I respaced everything that you mentioned and retab'ed the Makefile.in in question. I addressed of the your other concerns with the exclusion of: > Leading _ invades the ISO-C/C++ namespace. I am following what existed prior to my work on XPCOM. I did not modify the existing _IMPL_NS_COM, so I do not think that I should change my _IMPL_NS_COM. Does this matter that much? > Is this the best nsresult? It typically means "someone passed a null pointer as a param, and that's not valid". Probably not, but I don't want to risk any regressions. This is not new code but just has been moved around. > Wrong license boilerplate -- where did you copy this from? If I am copy parts of a file under one license to a new file, does this merit a new license? In any case, I made the modification...

Comment on attachment 75286 [details] [diff] [review] Patch 6 A sequel (and no doubt Futured, at this point) bug on the leading _ names should be filed, dougt and I talked about this earlier today. sr=brendan@mozilla.org

Leading _ invades the ISO-C/C++ namespace bug: 132601

Comment on attachment 75286 [details] [diff] [review] Patch 6 a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Checking in allmakefiles.sh; /cvsroot/mozilla/allmakefiles.sh,v <-- allmakefiles.sh new revision: 1.351; previous revision: 1.350 done Checking in db/mork/build/Makefile.in; /cvsroot/mozilla/db/mork/build/Makefile.in,v <-- Makefile.in new revision: 1.21; previous revision: 1.20 done Checking in db/mork/build/makefile.win; /cvsroot/mozilla/db/mork/build/makefile.win,v <-- makefile.win new revision: 1.8; previous revision: 1.7 done Checking in gfx2/src/Makefile.in; /cvsroot/mozilla/gfx2/src/Makefile.in,v <-- Makefile.in new revision: 1.16; previous revision: 1.15 done Checking in gfx2/src/makefile.win; /cvsroot/mozilla/gfx2/src/makefile.win,v <-- makefile.win new revision: 1.11; previous revision: 1.10 done Checking in js/src/liveconnect/Makefile.in; /cvsroot/mozilla/js/src/liveconnect/Makefile.in,v <-- Makefile.in new revision: 1.26; previous revision: 1.25 done Checking in js/src/liveconnect/makefile.win; /cvsroot/mozilla/js/src/liveconnect/makefile.win,v <-- makefile.win new revision: 1.24; previous revision: 1.23 done Checking in modules/libpr0n/decoders/mng/Makefile.in; /cvsroot/mozilla/modules/libpr0n/decoders/mng/Makefile.in,v <-- Makefile.in new revision: 1.8; previous revision: 1.7 done Checking in modules/libpr0n/decoders/mng/makefile.win; /cvsroot/mozilla/modules/libpr0n/decoders/mng/makefile.win,v <-- makefile.win new revision: 1.7; previous revision: 1.6 done Checking in xpcom/base/nscore.h; /cvsroot/mozilla/xpcom/base/nscore.h,v <-- nscore.h new revision: 1.49; previous revision: 1.48 done Checking in xpcom/build/Makefile.in; /cvsroot/mozilla/xpcom/build/Makefile.in,v <-- Makefile.in new revision: 1.44; previous revision: 1.43 done Checking in xpcom/build/nsXPCOM.h; /cvsroot/mozilla/xpcom/build/nsXPCOM.h,v <-- nsXPCOM.h new revision: 1.5; previous revision: 1.4 done Checking in xpcom/components/Makefile.in; /cvsroot/mozilla/xpcom/components/Makefile.in,v <-- Makefile.in new revision: 1.35; previous revision: 1.34 done Checking in xpcom/components/makefile.win; /cvsroot/mozilla/xpcom/components/makefile.win,v <-- makefile.win new revision: 1.33; previous revision: 1.32 done Checking in xpcom/components/nsComponentManager.cpp; /cvsroot/mozilla/xpcom/components/nsComponentManager.cpp,v <-- nsComponentManager.cpp new revision: 1.192; previous revision: 1.191 done Checking in xpcom/components/nsComponentManagerUtils.h; /cvsroot/mozilla/xpcom/components/nsComponentManagerUtils.h,v <-- nsComponentManagerUtils.h new revision: 3.19; previous revision: 3.18 done Checking in xpcom/glue/Makefile.in; /cvsroot/mozilla/xpcom/glue/Makefile.in,v <-- Makefile.in new revision: 1.9; previous revision: 1.8 done Checking in xpcom/glue/makefile.win; /cvsroot/mozilla/xpcom/glue/makefile.win,v <-- makefile.win new revision: 1.8; previous revision: 1.7 done Checking in xpcom/glue/nsCOMPtr.h; /cvsroot/mozilla/xpcom/glue/nsCOMPtr.h,v <-- nsCOMPtr.h new revision: 1.92; previous revision: 1.91 done Checking in xpcom/glue/nsDebug.cpp; /cvsroot/mozilla/xpcom/glue/nsDebug.cpp,v <-- nsDebug.cpp new revision: 3.62; previous revision: 3.61 done Checking in xpcom/glue/nsIGenericFactory.h; /cvsroot/mozilla/xpcom/glue/nsIGenericFactory.h,v <-- nsIGenericFactory.h new revision: 1.32; previous revision: 1.31 done Checking in xpcom/glue/nsIInterfaceRequestorUtils.h; /cvsroot/mozilla/xpcom/glue/nsIInterfaceRequestorUtils.h,v <-- nsIInterfaceRequestorUtils.h new revision: 3.5; previous revision: 3.4 done Checking in xpcom/glue/nsISupportsImpl.h; /cvsroot/mozilla/xpcom/glue/nsISupportsImpl.h,v <-- nsISupportsImpl.h new revision: 3.7; previous revision: 3.6 done Checking in xpcom/glue/nsIWeakReferenceUtils.h; /cvsroot/mozilla/xpcom/glue/nsIWeakReferenceUtils.h,v <-- nsIWeakReferenceUtils.h new revision: 3.2; previous revision: 3.1 done Checking in xpcom/glue/nsMemory.cpp; /cvsroot/mozilla/xpcom/glue/nsMemory.cpp,v <-- nsMemory.cpp new revision: 1.2; previous revision: 1.1 done Checking in xpcom/glue/nsMemory.h; /cvsroot/mozilla/xpcom/glue/nsMemory.h,v <-- nsMemory.h new revision: 1.3; previous revision: 1.2 done Checking in xpcom/macbuild/xpcomPPC.xml; /cvsroot/mozilla/xpcom/macbuild/xpcomPPC.xml,v <-- xpcomPPC.xml new revision: 1.14; previous revision: 1.13 done Checking in xpcom/sample/Makefile.in; /cvsroot/mozilla/xpcom/sample/Makefile.in,v <-- Makefile.in new revision: 1.17; previous revision: 1.16 done Checking in xpcom/sample/nsSample.cpp; /cvsroot/mozilla/xpcom/sample/nsSample.cpp,v <-- nsSample.cpp new revision: 1.14; previous revision: 1.13 done Checking in xpcom/sample/nsTestSample.cpp; /cvsroot/mozilla/xpcom/sample/nsTestSample.cpp,v <-- nsTestSample.cpp new revision: 1.9; previous revision: 1.8 done

RCS file: /cvsroot/mozilla/xpcom/components/nsCategoryManagerUtils.h,v done Checking in components/nsCategoryManagerUtils.h; /cvsroot/mozilla/xpcom/components/nsCategoryManagerUtils.h,v <-- nsCategoryManagerUtils.h initial revision: 1.1 done RCS file: /cvsroot/mozilla/xpcom/glue/nsComponentManagerUtils.cpp,v done Checking in glue/nsComponentManagerUtils.cpp; /cvsroot/mozilla/xpcom/glue/nsComponentManagerUtils.cpp,v <-- nsComponentManagerUtils.cpp initial revision: 1.1 done RCS file: /cvsroot/mozilla/xpcom/glue/objs.mk,v done Checking in glue/objs.mk; /cvsroot/mozilla/xpcom/glue/objs.mk,v <-- objs.mk initial revision: 1.1 done RCS file: /cvsroot/mozilla/xpcom/glue/standalone/Makefile.in,v done Checking in glue/standalone/Makefile.in; /cvsroot/mozilla/xpcom/glue/standalone/Makefile.in,v <-- Makefile.in initial revision: 1.1 done

This landed last night.