This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "make install" failing
- To: jpr at jpr dot com
- Subject: Re: "make install" failing
- From: Craig Burley <burley at gnu dot org>
- Date: Tue, 23 Jun 1998 09:28:40 -0400 (EDT)
- CC: egcs at cygnus dot com
>Since the last four or five days, "make install" is bombing with:
>
>Making info file `f/g77.info' from `../../egcs/gcc/f/g77.texi'.
>../../egcs/gcc/f/g77.texi:11455: Cross reference to nonexistent node `FGetC Intrinsic (subroutine)'.
>../../egcs/gcc/f/g77.texi:7237: Cross reference to nonexistent node `ImagPart Intrinsic'.
>../../egcs/gcc/f/g77.texi:7234: Cross reference to nonexistent node `RealPart Intrinsic'.
>../../egcs/gcc/f/g77.texi:6156: Cross reference to nonexistent node `Complex Intrinsic'.
>makeinfo: Removing output file `f/g77.info' due to errors; use --force to preserve.
>make[1]: *** [f/g77.info] Error 2
>make[1]: Leaving directory `/s/tools/egcsobj/gcc'
>make: *** [install-gcc] Error 2
Hmm, another familiar problem, but I can't recall exactly what the
fix was. I *think* it stemmed from not having any `intdoc.texi'
file (which is automatically generated), or having it strangely
be 0 bytes long, or something.
Oh, that rings a bell. I think it resulted from some invocation
of the relevant Makefile bits that caused the f/intdoc program to
fail when invoked (e.g. it didn't get built). The redirection
used on the command line nevertheless "touched" up an empty
f/intdoc.texi. (Or maybe it was f/ansify touching up an empty
f/intdoc.h0.)
So, my guess is either the CVS tree has run into this and someone
needs to fix it, or your source or build directory just needs
fixing up. If using a completely freshly obtained snapshot or
CVS updating doesn't work for you, it's probably a problem in the
database itself. Either way, it should be fixable by forcing
f/intdoc.h0 and f/intdoc.texi to be freshly updated from f/intdoc.in,
the actual original source file (well, there are others involved,
but that's the main one used to generate f/intdoc.texi).
Hmm, at least in egcs-ss-19980621, I don't see any obvious problem;
f/intdoc.texi exists, seems quite intact, etc. So it's either a
post-snapshot problem in the CVS tree, or just a problem on your
system.
I suppose one way to avoid this in the future is to have the
Makefile fragment not use command-line redirection (of stdout
anyway) and just pass the output tree as another argument to the
two programs, modifying them accordingly. If someone wants to do
this, go ahead and submit the patches to egcs-patch for our review.
This would presumably prevent null output files being produced
in cases where the programs themselves couldn't be linked.
tq vm, (burley)