On Fri, May 30, 2008 at 9:33 AM, Ruchi Lohani <[EMAIL PROTECTED]> wrote: > > Hi, > > I did compile npapi.h with NO_NSPR_10_SUPPORT defined. That removed the > errors on types (int32 etc) but gave new errors related to PRArenaPool etc > which is quite obvious with the current > library. I guess I should wait for the fix to happen for the bug filed.
You can work around this bug in several ways before the bug is fixed. 1. You can separate your code that needs npapi.h and your code that needs NSS headers into different source files, so that no source file includes both npapi.h and NSS headers. This is the best solution. 2. You can compile your code with -DNO_NSPR_10_SUPPORT to work around the typedef conflict. But you need to supply the typedef and defines that NSS headers need. You can do that as follows: #include "prtypes.h" /* typedef and defines for NSPR 1.0 compatibility */ #define PRArenaPool PLArenaPool typedef PRInt64 int64; /* add more as needed, see below */ /* Include NSS headers*/ #include "nss.h" If the two typedef/defines are not sufficient, you can add the following as needed: typedef PRUint16 uint16; typedef PRUint32 uint32; #define BITS_PER_BYTE PR_BITS_PER_BYTE typedef PRUint8 uint8; typedef PRUintn uint; #define PR_PUBLIC_API PR_IMPLEMENT typedef PRInt16 int16; typedef PRInt32 int32; 3. You can patch npapi.h or obsolete/protypes.h so that only one of them defines the types int16, uint16, int32, and uint32. Hopefully one of these methods is acceptable to you. Wan-Teh _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
