This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: new fixinclude problem on HP-UX
- To: Marco Franzen <Marco dot Franzen at thyron dot com>
- Subject: Re: new fixinclude problem on HP-UX
- From: Bruce Korb <bkorb at sco dot COM>
- Date: Tue, 28 Mar 2000 12:17:45 -0800
- CC: gcc-bugs at gcc dot gnu dot org, Bruce Korb <bkorb at gnu dot org>
- Organization: Santa Cruz Operations
- References: <38E0D159.F81A6E64@sco.com> <00032818550501.03884@Maidavale>
- Reply-To: Bruce Korb <bkorb at gnu dot org>
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