Re: Compiler ABI changes and XPCOM components

If developers use XPCOM "properly" by avoiding compiler linkages that 
are not extern C, a compiler upgrade should not cause any problems.

For example, if you decided to use nsStringArray directly from your 
component, you will have a mangled C++ import of this library  (of 
course, you are on shaky ground already cause this class isn't frozen).

When the compiler changes, this mangling name may be changed so that the 
symbol will no match between your component and xpcom.  Of course, maybe 
the symbols stay the same and all if fine.

There are tools on all the platforms which can enumerate imports. 
Component developer should ensure that they are not pulling in stuff 
that unfrozen or mangled.

Does this make sense?

Doug


Pete Collins wrote:
> Er, the whole point of XPCOM is to abstract binary libs from the 
> interfaces they implement.
> 
> Just to clarify, you are saying if i compile a libfoo.so that implements 
> say a frozen nsIFoo using gcc3, and drop it into a 1.0 distrubution it 
> isn't going to work?
> 
> This sort of defeats the purpose of using a COM architecture doesn't it?
> I thought any compiler (on a specific platform) could implement an 
> interface and everything in theory would be peachy.
> I don't see how upgrading a compiler is a new platform?
> 
> Doug, can you just explain this a little better?
> I realize this appears to be more of an issue w/ plug-in authors rather 
> than trunk surfers.
> 
> Thanks
> 
> --pete
> 
> 
> Doug Turner wrote:
> 
>> If Mozilla decides to upgrade to a compiler that does not have the 
>> same ABI as the current version, any built component may fail.  It is 
>> a possiblity that is introduced when upgrading to a new compiler 
>> without recompiling everything.  Effectively, it is a different platform.
>>
>> What does this mean to you?  If you build a component and it works 
>> fine in version 1.0 of Mozilla.  If and when Mozilla upgrades the 
>> compiler they use, your component will have to be rebuilt against the 
>> same compiler.
>>
>> This should not be a surprise to anyone.  It is the standard thing 
>> that happens when new compilers get release that have a different 
>> ABI.  Now, all of this could be nothing, but I (read Bradley Baetz) 
>> wanted to give you a heads up.
>>
>> So, when you see a @status FROZEN, note that this means it should work 
>> as long as the component and xpcom are built with the same compiler ABI.
>>
>> Comments, questions always welcome,
>>
>>
>> Doug Turner
>> [email protected]
>>
> 
>