On Sep 7, 2007, at 3:02 PM, chromatic wrote:
On Friday 07 September 2007 09:32:51 Patrick R.Michaud wrote:
Chromatic is already aware of this issue, but I thought I'd
file a ticket for it that others can hang information on.
Starting with r21103, Parrot won't build on my 64-bit platform.
It starts through the normal configure and make process, but then
ends with:
....
./parrot -o runtime/parrot/library/Data/Sort.pbc
runtime/parrot/library/Data/Sort.pir ./parrot -o
runtime/parrot/library/Digest/MD5.pbc
runtime/parrot/library/Digest/MD5.pir
./parrot -o runtime/parrot/library/dumper.pbc
runtime/parrot/library/dumper.pir ./parrot -o
runtime/parrot/library/Getopt/Obj.pbc
runtime/parrot/library/Getopt/Obj.pir
make: *** [runtime/parrot/library/Getopt/Obj.pbc] Segmentation fault
(core
dumped)
If I run Configure.pl with the --m=32 option, everything compiles
and runs cleanly (but is of course 32 bit).
Part of the problem is that there were a lot of commits to the
generated file
that didn't touch imcc.y. In the past couple of months, I see:
19207
19280
19281
19297
19334
19510
19833
19881
19954
19955
20254
This is a problem, of course, when we regenerate the file and
overwrite all of
these changes.
My guess is that reverting the changes to compilers/imcc/imcc.y and
compilers/imcc/imcparser.c from that patch and applying this patch
instead
may fix things.
If so, we need to backport all of the changes to
compilers/imcc/imcparser.c
from the commits listed previously into compilers/imcc/imcc.y and add
some
sort of metadata to compilers/imcc/imcparser.c such that it's obvious
that
it's a generated file so that we don't run into this problem again.
-- c
I currently pass maintainer to Configure.pl and the files aren't
auto-regenerated. I still get a successful build. If I touch imcc.l
and imcc.y to update their timestamps and rerun make, I get a lot of
warnings, but a successful build, and normal failures on make test.
Maybe FreeBSD/amd64 got lucky this time.
