new fixinclude problem on HP-UX

[Marco Franzen]

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.

(I know, all this would not have happened if I had used a fresh build tree
outside the source tree. But not all versions of Make support VPATH, and I like
to compile GNU Make with gcc and only once. Anyway, `make distclean' not making
distclean IS a bug.)

On Tue, 28 Mar 2000, Bruce Korb wrote:
> This snippet comes from gcc/fixinc/fixinc.svr4.
> I would think HP-UX would be using the new stuff,
> but to be sure, please check what `config.guess`
> returns.  

It returns `hppa1.1-hp-hpux10.20'.

> These are the targets that select the
> svr4 script:
[snippet from gcc/fixinc/mkfixinc.sh: some sysv, solaris and udk]

So, none of these. It should have selected `../fixinc.sh' (which, BTW, appears
a dangerous hack, see below).

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.

> The question is, should HP-UX use the new fixer or not?

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

I will try a new bootstrap after removing the generated fixinc.sh script.
Unfortunately, that little old HP machine is extremely slow, the successful
bootstrap of gcc-2.95.2 (with BOOT_CFLAGS='-g -O3') took 14 hours.
So I can tell you only tomorrow unless it fails early.

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
====================================

Could that not lead to an attempt to copy a file onto itself? If the file
exists but is considered out of date so that make invokes mkfixinc.sh? If it
is out of date it should be re-generated by the code later in the script.
Setting `fixincludes="${target}"' is probably not the best thing to do, at
least not without checking for that special case later (or removing the file
if it exists).

Thanks, Bruce, for pointing me to the fact that the fixinc.sh script is
generated. (Its header says only it is part of GNU CC, which sounds like
ultimate source file, although it is only a verbatim copy of one.)

Cheers,

-- Marco
{please ignore any confidentiality clause that might be appended}
-----------------------------------------------------------------
This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email
is strictly prohibited.
If you have received this email in error, please notify the
Thyron IT Administrator on +44 (0)1923 236 050 or
send an email to mail-admin@thyron.com.
Thank You