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]