This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: snapshot 19990608 libstdc++ check error
- To: "'Robert Lipe'" <robertlipe at usa dot net>
- Subject: RE: snapshot 19990608 libstdc++ check error
- From: "Eric Raskin" <ehr at listworks dot com>
- Date: Wed, 9 Jun 1999 17:30:13 -0400
- Cc: <egcs at egcs dot cygnus dot com>, <law at cygnus dot com>
- Reply-To: <ehr at listworks dot com>
Robert:
I got the things into inclhack.def and re-ran autogen. The inclhack.sh script generated
has my changes, so I know this part works. The problem I'm having is in mkfixinc.sh.
Inside the script, we have:
.
.
.
case $machine in
.
.
.
i[34567]86-dg-dgux* | \
m88k-dg-dgux*)
fixincludes=fixinc.dgux
;;
.
.
.
esac
# IF there is no include fixing,
# THEN create a no-op fixer and exit
#
if test -z "$fixincludes"
then
(echo "#! /bin/sh" ; echo "exit 0" ) > ${target}
chmod 755 ${target}
exit 0
fi
.
.
.
This is the problem. If I erase the fixincludes assignment in the case statement, then
test -z "$fixincludes" is true and an empty script gets built. If I leave it defined
in the case statement, then it uses the old (bad) fixinc.dgux script. If I leave it
defined but remove the actual fixinc.dgux file, then the script decides to build a
new one and everything is fine.
How should we identify that the platform should re-gen fixincludes on each run, rather
than using a dummy file or an old script? What do you thing about the work 'regen' or
something similar (ie. assign fixincludes=regen in order to get the stuff rebuilt)?
Eric Raskin
> -----Original Message-----
> From: Robert Lipe [mailto:robertlipe@usa.net]
> Sent: Wednesday, June 09, 1999 5:21 PM
> To: Eric Raskin
> Cc: egcs@egcs.cygnus.com; law@cygnus.com
> Subject: Re: snapshot 19990608 libstdc++ check error
>
>
> > They should work, since the system compiler is gcc 2.7.2.
> Unless gcc
> > handles asm() differently now?
>
> [ I defer ]
>
> > I've done some checking on what inclhack.def defines, and it doesn't
> > define the same things as fixinc.svr4!! The NULL patches are
>
> Right. This is why fixinc.svr4 hasn't been erased yet. The
> SVR4-specific fixes have not yet been grafted into
> inclhack.def. Since
> you don't need most of the fixes, your task is therefore relatively
> small. :-)
>
> > 1) DG/UX patch to _int_varargs.h for m88k/i386
> compatibility with one
> > file
>
> That one is probably going to have to actually be written.
>
> > 2) 'struct exception' in math.h clobbers 'class exception' in
> > gcc/cp/inc/exception
>
> Should be handled by math_exception in inclhack.def
>
> > 3) [Not sure about this one] 'struct queue' in queue.h
> clobbers 'class
> > queue' in libstdc++/stl/stl_queue.h
>
> This doesn't exist in inclhack.def but using the fix from fixincl.svr4
> as inspiration should be trivial to blast in.
>
> > On a slightly different tack, how do I get the inclhack.def file
> > to be used? I downloaded autogen and rebuilt everything using the
> > genfixes script.
>
>
> [ Manfred, Bruce, Jeff, now that we have sensible makefile targets in
> gcc/fixinc/, should 'genfixes' be blasted? ]
>
> > My first attempt was to remove the 'fixinc.dgux' from
> > 'fixincludes=fixinc.dgux' in mkfixinc.sh. This didn't work -- it
> > created a dummy file that did nothing.
>
> You're probably best off to just remove the DGUX references in
> mkfixinc.sh.
>
> It's entirely possible that there are makefile dependencies that are
> missing. See if removing zero or more of $(OBJDIR)/gcc/fixinc.sh,
> .../fixincl, or .../stmp-fixinc helps. (If so, feel free to submit
> fixes for Makefile.in. :-)
>
> > My next try, which is running now, leaves 'fixincludes=fixinc.dgux'
> > but removes the file. It looks like that will cause it to be
> > re-generated from the sources. Is this correct?
>
> But you don't want fixinc.dgux any more. You want it to
> build a fixincl
> binary that does this stuff for you.
>
> Think of it as a two step process. You can do the steps in
> either order
> you like once you realize you don't cross the finish line
> until both are
> done.
>
> 1) Getting your changes into inclhack.def and getting the
> "right" things
> built from it. This requires tinkering with autogen.
>
> 2) Converting your target to use those "right" things above.
>
> fixinc/README contains some good hints.
>
> RJL
>