From:	Andrew Crabtree <andrewc AT typhoon DOT rose DOT hp DOT com>
Message-Id:	<199801290902.AA068634549@typhoon.rose.hp.com>
Subject:	Re: iostream concern
To:	dj AT delorie DOT com (DJ Delorie)
Date:	Thu, 29 Jan 1998 1:02:29 PST
Cc:	robert DOT hoehne AT gmx DOT net, djgpp-workers AT delorie DOT com
In-Reply-To:	<199801290136.UAA25708@delorie.com>; from "DJ Delorie" at Jan 28, 98 8:36 pm
Reply-To:	andrewc AT rosemail DOT rose DOT hp DOT com

 
> Shouldn't we just fix the djgpp includes, rather than letting gcc
> "fix" them itself?  I've *never* run fixincludes on djgpp's includes.
There are two parts to this.  The first is fixincludes, which is 
very easy to disable in the configure.in file.  The second is the 
part that supplies the generated stddef.h file and such.  This too
can be disabled I think.  Jeffrey Law was very insistent that 
fixincludes should *not* be disabled, but couldn't come up 
with anything important that they would do for DJGPP besides 
the struct exception problem in math.h (even then I think it only 
fixes one of the math.h headers).  I think it is safe to disable them,
assuming that we run them manually to see what they do and then 
fix the headers with the appropriate changes.


> > headers in $DJDIR/lib/gcc-lib/djgpp/2.80/include, so gcc 2.8.0 will
Will this support the full name with LFN too (i386-pc-msdosdjgpp say)?

> > that we modify
> > djgpp.env in a may, that $DJDIR/include is _NOT_ part of
> > $C_INCLUDE_PATH,
> 
> If we do this, how will gcc find djgpp's include files?  I'm thinking
> of, say, <go32.h>
I don't follow the C_INCLUDE_PATH exactly, but it should be possible
to have gcc search in the new directories first and then fall back to 
the old ones.

> > past some problems with it, I would include libstdcxx.a in gpp280b.zip
> > and would have in lgpp280b.zip only libgxx.a . Are you agree?
> 
> Why not just leave it in lgp*b.zip?  People are used to downloading it
> anyway, and it includes all the other C++ libraries.
I think maybe, since libgpp is distributed separately (as source), from
libio and libstdcxx and the c++ compiler, and since it is slated for
obsolescence, that it makes sense to have libgpp in a separate package
from the rest.  People who are programming in c++ will have to have 
libstdcxx and libio, so might as well throw them together.  Less zip
files to download.  I suppose it could be a problem for people 
with slow links, but I think it should still be fairly small.  The 
last pg++ (which had everything in one file), was under 2MB, and I didn't
strip debug symbols out of the libs (I did strip cc1plus).

- Raw text -