This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: snapshot 19990608 libstdc++ check error


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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]