Nelson Bolyard wrote:
>I'd like to get a dependency tools for Windows again. I guess there's one as
>part of Mozilla, but I don't want to have to build the whole browser to get a
>dependency tool.
>
>
While the Mozilla build system can build its own, I'm not sure NSS is up
to the task, speci
Wan-Teh Chang wrote:
>On Sun, Feb 24, 2008 at 3:15 AM, Neil <[EMAIL PROTECTED]> wrote:
>
>
>>Even in depend builds, Mozilla's root makefile still automatically blows away
>>all of dist/include to avoid such problems... do dist/public and dist/private
>>need to be added to that list too?
>>
On Sun, Feb 24, 2008 at 3:15 AM, Neil <[EMAIL PROTECTED]> wrote:
>
> Even in depend builds, Mozilla's root makefile still automatically blows
> away all of dist/include to avoid such problems... do dist/public and
> dist/private need to be added to that list too?
Yes, just add a comment to expl
Neil wrote, On 2008-02-24 03:15:
> Wan-Teh Chang wrote:
>
>> I'm not sure if it's still worth implementing the real fix now -- it is
>> easier to ask the affected people to blow away their dist/public/nss
>> directory in their build trees.
>>
>>
> Even in depend builds, Mozilla's root makefile s
Wan-Teh Chang wrote:
>I'm not sure if it's still worth implementing the real fix now -- it is easier
>to ask the affected people to blow away their dist/public/nss directory in
>their build trees.
>
>
Even in depend builds, Mozilla's root makefile still automatically blows
away all of dist/in
Neil wrote, On 2008-02-23 15:34:
> Nelson Bolyard wrote:
>
>> Neil, here's what I find strange about all this.
>>
>> The code you cite builds and runs, without error, continuously, on a
>> whole bunch of tinderbox systems
>>
> That's because a number of factors are required to trigger this "bug":
>
On Sat, Feb 23, 2008 at 9:27 AM, Neil <[EMAIL PROTECTED]> wrote:
> Neil wrote:
>
> > I've got the real one in dist/private/nss and an outdated one in
> > dist/public/nss
>
> Looks like tpol is suffering from the same problem, but nobody noticed
> since KaiRo is away attending FOSDEM:
>
>
> ht
Nelson Bolyard wrote:
>Neil, here's what I find strange about all this.
>
>The code you cite builds and runs, without error, continuously, on a whole
>bunch of tinderbox systems
>
That's because a number of factors are required to trigger this "bug":
1. The bug does not affect clobber builds,
Nelson Bolyard wrote, On 2008-02-23 13:08:
> Neil, here's what I find strange about all this.
>
> The code you cite builds and runs, without error, continuously, on a whole
> bunch of tinderbox systems, including
[snip]
> I wonder what is different about your build environment. I suppose that
>
Neil wrote, On 2008-02-23 05:07:
>> pkixt.h contains
>>
>> typedef struct PKIX_PL_OcspCertIDStruct PKIX_PL_OcspCertID;
>
> ... but that depends on which pkixt.h you look at! I've got the real one
> in dist/private/nss and an outdated one in dist/public/nss...
>
> Note that the root makefile exp
Neil wrote:
> I've got the real one in dist/private/nss and an outdated one in
> dist/public/nss
Looks like tpol is suffering from the same problem, but nobody noticed
since KaiRo is away attending FOSDEM:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports&maxdate=1203651200&hour
Neil wrote:
> pkixt.h contains
>
> typedef struct PKIX_PL_OcspCertIDStruct PKIX_PL_OcspCertID;
... but that depends on which pkixt.h you look at! I've got the real one
in dist/private/nss and an outdated one in dist/public/nss...
Note that the root makefile explicitly removes dist/include to av
Nelson Bolyard wrote:
>In any case, I'd guess the right "fix" is for pkix_pl_oscpcertid.h to include
>pkixt.h, since it depends on types defined there.
>
>
The build still didn't succeed. This is also now with a normal MSYS
VC7.1 SeaMonkey build, which produces this (partial) output:
make[6]:
Wan-Teh Chang wrote:
>Can you try adding a forward declaration to pkixt.h
>struct PKIX_PL_OcspCertIDStruct;
>before that typedef?
>
>
Sorry, that seems to make no difference.
--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
de
It doesn't seem to be my cross-compiler; I updated my regular MSYS/VC7.1
build for comparison and lo and behold it won't compile
pkix_pl_ldapcertstore.c either. A build on a third PC oddly fails to
stop after that error and instead continues until it fails to load
shlibsign due to a missing imp
Neil wrote, On 2008-02-22 17:05:
> On second thoughts the problem seems to be that someone is including
> pkix_pl_oscpcertid.h before pkixt.h
Doesn't the compiler name the .c file that it's trying to compile when
this error occurs?
In any case, I'd guess the right "fix" is for pkix_pl_oscpcert
Neil wrote:
> Wan-Teh Chang wrote:
>
>> On Fri, Feb 22, 2008 at 4:35 PM, Neil <[EMAIL PROTECTED]> wrote:
>>
>>> pkix_pl_oscpcertid.h contains:
>>>
>>> struct PKIX_PL_OcspCertIDStruct {
>>>CERTOCSPCertID *certID;
>>>PRBool certIDWasConsumed;
>>> };
>>>
>>> /* see source file for fun
Wan-Teh Chang wrote:
>On Fri, Feb 22, 2008 at 4:35 PM, Neil <[EMAIL PROTECTED]> wrote:
>
>
>>pkix_pl_oscpcertid.h contains:
>>
>> struct PKIX_PL_OcspCertIDStruct {
>>CERTOCSPCertID *certID;
>>PRBool certIDWasConsumed;
>> };
>>
>> /* see source file for function documentation */
>
On Fri, Feb 22, 2008 at 4:35 PM, Neil <[EMAIL PROTECTED]> wrote:
> pkix_pl_oscpcertid.h contains:
>
> struct PKIX_PL_OcspCertIDStruct {
> CERTOCSPCertID *certID;
> PRBool certIDWasConsumed;
> };
>
> /* see source file for function documentation */
>
> PKIX_Error *pkix_pl_OcspCer
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation */
PKIX_Error *pkix_pl_OcspCertID_RegisterSelf(void *plContext);
PKIX_Error *
PKIX_PL_OcspCertID_Create(
PK
20 matches
Mail list logo
