Re: Re[3]: symbol nsCRT::strcmp not def.at link time (Was: Re: build problem)

Hi,

got it. So in which list are the guys responsible for this aspect of things?
dev-builds? dev-apps-firefox? There is no dev-xpcom mailing list :(

However, as far as nspr is concerned, do you confirm that the nspr API is
stable or backwards compatible among all "deployed" firefox versions? (ie
2.x, 3.0.x, 3.5.x)

Regards and thanks for your help.
Sebastien

On Wed, Jan 6, 2010 at 12:58 PM, Konstantin Andreev <[email protected]>wrote:

> Hello, Sébastien.
>
> Sorry, I can not advice you about Gecko extensions compatibility. This
> problem is out of NSPR scope.
>
> If it matters, nsCRT::strcmp is just a wrapper around PL_strcmp, defined in
> nsCRT.h, you can use them interchangeably.
>
> Best regards,
> --
> Konstantin Andreev.
>
>
> On Tue, 05 Jan 2010, Sébastien Lorquet wrote:
>
>>
>> Well, I succeeded in building my extension with the following tricks:
>> -define XPCOM_GLUE
>> -define XPCOM_GLUE_USE_NSPR
>> -link with libplc4
>>
>> However I'm worried the range of version compatible with such an
>> extension. How do I deal with retrocompatibility with previous
>> firefoxes/other gecko products?
>>
>> A simple example: I was unable to use nsIXPConnect using xul-sdk 1.9.0.6
>> with firefox 3.5.6, but it works when I use xul-sdk 1.9.1.4.
>>
>> The related code is:
>>
>> #include "nsServiceManagerUtils.h"
>> #include "nsIXPConnect.h"
>> (...)
>> nsCOMPtr<nsIXPConnect> vXpConnect = do_GetService(nsIXPConnect::GetCID(),
>> &nr);
>> NS_ENSURE_SUCCESS(nr,nr);
>>
>> without it my extension is 100% useless.
>>
>> Such a strong dependency on the sdk version afraids me. Is my extension
>> only compatible with ff 3.5.6, or also with 3.0.x previous versions? How do
>> you deal with that in practice? Do I have to provide separate extensions for
>> different firefox branches?
>>
>> I know google gears deals with this but I would like to keep as far as
>> this thing as possible (unless impossible).
>>
>> Regards
>> Sebastien
>>
>> On Tue, Jan 5, 2010 at 3:25 PM, Konstantin Andreev wrote:
>>
>>  Your problem is not related to NSPR, because:
>>>
>>>   NSPR has symbol PL_strcmp, which is defined in plstr.h and exported by
>>> libplc4.so.
>>>
>>> Personally, I have noted that Thunderbird 2.* sources use nsCRT::strcmp
>>> everywhere.
>>> But in Thunderbird 3.0 release (08 Dec 2009) the nsCRT::strcmp has been
>>> changed to PL_strcmp everywhere.
>>>
>>> On Wed, 30 Dec 2009, Sébastien Lorquet wrote:
>>>
>>>  I am new to these lists so I don't know if my problem is related to the
>>>> nspr mailing list or the extensions mailing list. I'll choose one in the
>>>> next posts.
>>>>
>>>> I have made an xpcom object to be bundled in a firefox extension to
>>>> expose new DOM Javascripts objects. I used the mozilla code base from mxr as
>>>> a reference.
>>>>
>>>> So far, I have resolved all issues related to the extension itself, the
>>>> individual cpp files are compiling fine.
>>>>
>>>> However, I have a link time problem.
>>>>
>>>> The macro NS_DOMCI_EXTENSION_ENTRY_BEGIN defined in nsIDOMClassInfo.h
>>>> relies on nsCRT::strcmp from nsCRT.h
>>>>
>>>> This symbol is not defined a link time.
>>>> #define NS_DOMCI_EXTENSION_ENTRY_BEGIN(_class)          \
>>>>  if (nsCRT::strcmp(aName, #_class) == 0) {       \
>>>>   static const nsIID* interfaces[] = {
>>>>
>>> _______________________________________________
> dev-tech-nspr mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-nspr
>
_______________________________________________
dev-tech-nspr mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-nspr