On Mon, 30 Jun 2008, chromatic wrote:
> > On Mon, Jun 30, 2008 at 3:55 PM, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> > > Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the
> > > following produce a working Parrot, using 64-bit ints?
> > >
> > > perl Configure.pl --intval="long long int" --opcode="long long int"
> > >
> > > If fails for me on C<make> while building PGE.
> > >
> > > ../../parrot -o PGE.pbc --output-pbc PGE.pir
> > > ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir
> > > --output=PGE/builtins_gen.pir PGE/builtins.pg
> > > make[1]: *** [PGE.pbc] Segmentation fault
> > > make[1]: *** Deleting file `PGE.pbc'
> > >
> Ron, do you get any warning messages during Configure? I see:
>
> Figuring out how to pack() Parrot's types...Configure.pl: Unable to find a
> functional packtype for intvalsize.
> 'q' failed: Invalid type 'q' in pack at config/auto/pack.pm
> line 62.
That's an irrelevant historical artifact. A very long time ago, parrot
used perl to create "packfiles" (now known as .pbc files), and so had to
have a way to pack INTVALs and opcodes. If your perl is not natively
64-bit and is not configured with 64-bit integers (e.g. configured with
C<sh Configure -Duse64bitint>, then you will see this warning.
Since parrot doesn't use perl to create packfiles, this warning is
irrelevant. I have no idea why Configure.pl still probes for it.
> There are also plenty of build warnings, such as:
>
> src/headers.c: In function ‘Parrot_destroy_header_pools’:
> src/headers.c:912: warning: cast to pointer from integer of different size
It's certainly possible that casting from a 64-bit integer down to a
32-bit pointer could cause a problem, though if the integer involved is
small, then there shouldn't be a problem.
More generally, though, I don't think this configuration has worked for a
very long time. Looking back at my (very incomplete) archives, the last
success I had with this configuration was on Dec 19, 2002. There is a
very old ticket [perl #18189] on this issue too. There are some remarks
in there that might still be relevant.
(Odd. That ticket seems to be marked resolved, though I thought by
replying to it I would have reopened it.)
--
Andy Dougherty [EMAIL PROTECTED]
