From: Andrew Crabtree 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 Precedence: bulk > 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, 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).