Thanks for trying this out. I assume that you're trying the ponie-2 tarball from CPAN? If so, that's somewhat out of date, so this might be part of the problems (but not all, I suspect).
All the errors you've reported so far appear to come from parrot, rather than being ponie specific so it's probably better to shift this thread over to the perl6-internals list, where the parrot folks live. I'm not sure if anyone has ever tried to build parrot on Solaris 2.5, or on Solaris x86. I've had some "fun" building it on prerelease Sparc Solaris 10, but that was almost all down to ICU, and occurred much later in the build than the problems you seem to be seeing. On Tue, Dec 28, 2004 at 10:56:23PM -0600, [EMAIL PROTECTED] wrote: For all on perl6-internals, the first message of this thread is http://www.nntp.perl.org/group/perl.ponie.dev/359 and refers to the asctime_r errors. > Now I see: > ops/core_ops.c > ops/io.ops: In function `Parrot_tell_i_i_p': > ops/io.ops:507: warning: right shift count >= width of type > ops/core_ops_prederef.c > ops/io.ops: In function `Parrot_pred_tell_i_i_p': > ops/io.ops:507: warning: right shift count >= width of type > ops/core_ops_switch.c > ops/io.ops: In function `switch_core': > ops/io.ops:507: warning: right shift count >= width of type > ops/core_ops_cg.c > ops/io.ops: In function `cg_core': > ops/io.ops:507: warning: right shift count >= width of type > > which points to: > op tell(out INT, out INT, in PMC) { > if ($3) { > PIOOFF_T pos; > pos = PIO_tell(interpreter, $3); > $1 = (INTVAL)(pos >> 32); > $2 = (INTVAL)(pos & 0xffffffff); > } > goto NEXT(); > } > > > which means my PIOOFF_T is less than 32 bits? Hmm ... I suspect that it means that your PIOOFF_T is exactly 32 bits, as the error is ">=", not ">", and a shift of the width of the type is undefined behaviour in C. Which would mean that the parrot code is buggy for the case of non- large-files systems. Are you using the Sun compiler, or gcc? I'm not sure which would produce that warning, but my hunch would be the Sun compiler as shifts happen to be modulo 32 on x86, but IIRC are modulo 256 on Sparc, hence it would be something I'd expect a Sun compiler to spot, as it would be an easy portability gotcha to fall into on Solaris. Nicholas Clark
