From: Andy Dougherty [mailto:[EMAIL PROTECTED]]
>
> > Btw, can anyone advise me on getting an actual account on
> > a natively 64-bit machine somewhere? I don't really like
> > the model of checking in broken code, waiting for the tinderbox
> > to get around to testing it, blindly fixing things,
> Btw, can anyone advise me on getting an actual account on a natively
> 64-bit machine somewhere? I don't really like the model of checking in
> broken code, waiting for the tinderbox to get around to testing it,
> blindly fixing things, and repeating. Especially when the tinderbox
> machines fre
On Tue, 10 Sep 2002, Andy Dougherty wrote:
> > 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> > INTVAL='long long'. This configuration used to work quite recently.
Thanks, applied
(by me).
--
Andy Dougherty [EMAIL PROTECTED]
On Tue, Sep 10, 2002 at 07:53:10PM +0100, Nicholas Clark wrote:
> On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote:
> > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
> > the prototypes are hidden in the C file, not in a shared header file, the
> > compiler
On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote:
> This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since
> the prototypes are hidden in the C file, not in a shared header file, the
> compiler doesn't warn about them.) Upon reflection, however, since the
extern
On Mon, 9 Sep 2002, Andy Dougherty wrote:
> 64-bit-int builds appear to be broken. This is from Linux/SPARC with
> INTVAL='long long'. This configuration used to work quite recently.
The immediate culprit was config/gen/core_pmcs.pl, which now puts out
prototypes of
extern void Parrot
