Re: new fixinclude problem on HP-UX

[Bruce Korb <bkorb at sco dot COM>]

Marco Franzen wrote:
> 
> As turned out, the bug is not HP-UX specific.
> 
> It was caused by `make distclean' not removing all architecture-dependently
> generated files, in particular not "gcc/fixinc.sh".
> 
> I would have seen this earlier if gcc/fixinc/mkfixinc.sh put a warning
> comment at the beginning, as the other generators do. This could be construed
> another flaw.

Well, it would be easy enough to put a comment at the beginning
of the scripts that get copied to the gcc/ directory before being run.
gcc/fixinc.sh did not used to depend on anything.  The assumption was
that it was a fairly static process, not requiring redoing.  Since then,
dependencies have been added to the rule and now, you are right,
`make distclean' ought to clean it up.

> It returns `hppa1.1-hp-hpux10.20'.
> 
> > These are the targets that select the
> > svr4 script:
> [...]
> 
> So, none of these. It should have selected `../fixinc.sh' (which, BTW, appears
> a dangerous hack, see below).

Curious.  What was it doing running the svr4 or iris script then?
Those scripts got copied up to the gcc directory somehow at some point.

> In fact, the `make bootstrap' output shows, that mkfixinc.sh was not run at all!
> The real bug seems to be that `make distclean' does not remove the
> architecture-dependently generated fixinc.sh script.

If the fixinc.sh script exists in the gcc directory,
then that script is presumed current (a few dependencies
notwithstanding).

> Apparently, the SysV.4 fixer fails on this platform.

I think we know that now :-)

> I will try a new bootstrap [[...]] took 14 hours.
> So I can tell you only tomorrow unless it fails early.

OK.

> BTW, looking at gcc/fixinc/mkfixinc.sh, I am a bit wary whether building in the
> source tree would work reliably for machines not mentioned in the case clause:
> 
> ===================================
> target=../fixinc.sh
> fixincludes="${target}"
> .................................................
> #  IF the fixer is supplied in our source directory,
> #  THEN copy that into place
> #
> if test -f ${srcdir}/"${fixincludes}"
> then
>     echo copying ${srcdir}/$fixincludes to ${target}
>     cp ${srcdir}/$fixincludes ${target}
>     chmod 755 ${target}
>     exit 0
> fi

I think I originally meant to set fixincludes to $machine,
something that would never be a findable file.

> Could that not lead to an attempt to copy a file onto itself?

Probably, in cases where gcc/fixinc.sh is considered out-of-date,
so make tries to rebuild it.  I would expect it to be a rather
uncommon problem, but it is clumsey anyway.  Fixed, thanks.

> Thanks, Bruce, for pointing me to...

Thank you for taking the time to figure out what is really going on.

Regards,
	Bruce