Re: new fixinclude problem on HP-UX

[Bruce Korb <bkorb at sco dot COM>]

Marco Franzen wrote:
> Are you sure that this fixincl is responsible at all?

> =====================================================
> 
> The probably responsible section of fixinc.sh:
> =====================================================
> # In limits.h, put #ifndefs around things that are supposed to be defined
> # in float.h to avoid redefinition errors if float.h is included first.
> # Solaris 2.1 has this problem.
> 
> file=limits.h
> base=`basename $file`.$$
> if [ -r ${LIB}/$file ]; then
>   file_to_fix=${LIB}/$file
> else
>   if [ -r ${INPUT}/$file ]; then
>     file_to_fix=${INPUT}/$file
>   else
>     file_to_fix=""
>   fi
> fi

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.  These are the targets that select the
svr4 script:

        *-*-sysv4* | \
        i[34567]86-*-sysv5* | \
        i[34567]86-*-udk* | \
        i[34567]86-*-solaris2.[0-4] | \
        powerpcle-*-solaris2.[0-4] | \
        sparc-*-solaris2.[0-4] )
                fixincludes=fixinc.svr4
                ;;

The same snippet also appears in fixinc.irix,
but I am sure HP-UX won't match that one :-).

> Do I need to run AutoGen or something like that?

AutoGen should never be necessary unless you make changes
to the generated file predecessors:

  fixinc/inclhack.def or fixinc/*.tpl

The question is, should HP-UX use the new fixer or not?
I do not have access to an HP-UX.  You can force the
new fixer by twiddling with fixinc/mkfixinc.sh in obvious ways.
If the resultant changes do not break the port,
then add a clause to fixinc/mkfixinc.sh:

	*hpux* )  : ;;

(but do a better job.  I don't know the output of config.guess
for your platform.  You want to be sure of a match IFF the new
stuff works correctly when the match succeeds.)

> Or is the new way of doing fixincludes not the default yet?
> In that case I would have a new problem with the old fixincludes
> rather than a problem with the new fixincludes.

All ports now use the gcc/fixinc/mkfixinc.sh script to determine how
to fix the includes.  When that script finishes, some sort of
script will be copied into gcc/fixinc.sh, which one depends
on the platform.  The goal is to make it always the same,
but we are not there yet.

> > $ find . -type f | ../../fixincl
> 
> I have no program fixincl in the aborted build tree,
> only a shell script fixinc.sh script and a directory fixinc:

The "fixinc.sh" is most likely a copy of fixinc/fixinc.svr4.

> The change your fixincl program applies seems to be quite exactly
> the reverse of the change apparently done by fixinc.sh

??  The sample I put in my email was the snippet you sent,
plus another copy of that that I had edited to remove the
"ifndef" clauses.  The fixinc.svr4 script does not take the
precaution of skipping the fix when "ifndef DBL_MAX" is present,
hence the bug in your port.

The generated script looks like this (sans sed commands):

    #
    # Fix Limits_Ifndefs
    #
    case "${file}" in ./limits.h | \
        ./sys/limits.h )
    if ( test -z "`egrep 'ifndef[       ]+FLT_MIN' ${file}`"
       ) > /dev/null 2>&1 ; then
    fixlist="${fixlist}
      limits_ifndefs"
    if [ ! -r ${DESTFILE} ]
    then infile=${file}
    else infile=${DESTFILE} ; fi

    sed -e '...' \
          < $infile > ${DESTDIR}/fixinc.tmp
    rm -f ${DESTFILE}
    mv -f ${DESTDIR}/fixinc.tmp ${DESTFILE}
    fi # end of bypass 'if'
    ;; # case end for file name test
    esac