Closed Bug 130405 Opened 22 years ago Closed 22 years ago

Make glue library useable

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dougt, Assigned: dougt)

Details

(Keywords: topembed+)

Attachments

(2 files, 5 obsolete files)

my review comments (can't seem to use patch mgr, too big?)
10.24 KB, text/plain
Details
Patch 6
42.63 KB, patch
brendan
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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.
Attached patch Patch v.1 (obsolete) — — Splinter Review 
Only has build on windows/gmake.
Keywords: mozilla1.0, topembed
Keywords: topembed → topembed+
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
Attachment #73773 - Flags: superreview+
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 !!
Attachment #73773 - Flags: review+
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 ?
Attachment #73773 - Flags: review+ → needs-work+
>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?
Attached patch Patch v.2 (obsolete) — — Splinter Review 
Fixed cls's concerns.
Attachment #73773 - Attachment is obsolete: true
Comment on attachment 73789 [details] [diff] [review]
Patch v.2

carry over sr
Attachment #73789 - Flags: superreview+
>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.
Attached patch patch v.3 (obsolete) — — Splinter Review 
Compiles on linux.
Attachment #73789 - Attachment is obsolete: true
>>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.
Attachment #73824 - Flags: superreview+
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
Attachment #73824 - Flags: review+
Attached patch patch v.4 (obsolete) — — Splinter Review 
rolling in cls's comments.
Attachment #73824 - Attachment is obsolete: true
Comment on attachment 73966 [details] [diff] [review]
patch v.4

rolling in r/sr.
Attachment #73966 - Flags: superreview+
Attachment #73966 - Flags: review+
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.
Attachment #73966 - Attachment is obsolete: true
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.
Attached patch patch 5 (obsolete) — — Splinter Review 
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
Attached patch Patch 6 — — Splinter Review 
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...
Attachment #75087 - Attachment is obsolete: true
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
Attachment #75286 - Flags: superreview+
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
Attachment #75286 - Flags: approval+
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: