Re: Serious (semi-)infinite loop

[Tom Tromey]

>>>>> "Tim" == Tim Van Holder <address@hidden> writes:

>> Oh, yeah -- I just remembered that this Makefile.am relies on a
>> hacked automake 1.4 and does some other bad things.  For instance
>> it has both

Tim> That seems odd, as it is part of the gcc tree. And as I
Tim> understand it they are reluctant to rely on hacked versions of
Tim> tools.

libffi wasn't originally part of the gcc tree.  We brought it into the
tree with the rest of the Java runtime.  This code was developed
differently and required a hacked automake (I know, I did the
hacking...).

For instance the libffi Makefile.am overrides the .c.o suffix rule so
that objects are created in subdirs.  This is a hack.  In 1.5 you'll
handle this differently ("subdir-objects"), but even then you can't
have several files potentially compile to the same object.

>> `src/mips/n32.S' and `src/mips/n32.s'.  These aren't even
>> distinguishable on Windows.

Tim> This is apparently fixed in the current version of libffi; the
Tim> version that is part of gcc is an older one, where the situation
Tim> persists.

Anthony, is a merge of the two trees in the works?

>> So making it work with 1.5 isn't a priority.

Tim> Well, that leaves me in a bind, as it makes me unable to
Tim> configure the gcc tree.

Are you trying to use automake 1.4h on the gcc tree?  If so, that is
very helpful.  It is the kind of testing we could use.

However, in this particular case I'm quite certain that the gcc libffi
does some things which are not really allowed.  The right thing to do
is fix gcc/libffi/Makefile.am so that it is more correct.  Probably
this change can't go in until automake 1.5 is officially released :-(.
But at the very least you could do testing with the fix in place.

Tom