Message-ID: <34D50E2D.F3E7175D@gmx.net> Date: Mon, 02 Feb 1998 01:07:09 +0100 From: Robert Hoehne Organization: none provided MIME-Version: 1.0 To: DJ Delorie CC: djgpp-workers AT delorie DOT com Subject: Re: iostream concern References: <199801290136 DOT UAA25708 AT delorie DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk DJ Delorie wrote : > > Shouldn't we just fix the djgpp includes, rather than letting gcc > "fix" them itself? I've *never* run fixincludes on djgpp's includes. Of course, fixing the DJGPP headers would be the best solution. This was also the reason why I included in my mail the diffs. > > To solve this, I will include in the gcc280b.zip archive the fixed > > headers in $DJDIR/lib/gcc-lib/djgpp/2.80/include, so gcc 2.8.0 will > > find them before the standard headers assuming here, 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, gcc (or bettet cpp) will be configured to search the following directories (if they exists) for include files: /usr/local/include $(DJDIR)/djgpp/include $(DJDIR)/lib/gcc-lib/djgpp/2.80/include $(DJDIR)/include These paths are hardcoded in cpp.exe (not here that there is really $DJDIR used, which is examined at runtime). That means, cpp will be able to find the headers without having any section in the djgpp.env. But if we place there a section for setting for instance $C_INCLUDE_PATH, then this directory is searched _before_ all the above mentioned and cpp will not find the fixed headers, since the old ones are found already. > > And to the concrete problem (see above with _G_fpos_t) gcc280b.zip > > (and/or) the C++ libarry will come with a file file > > > > $DJDIR/djgpp/include/_G_config.h > > This doesn't make sense. There is no djgpp directory in the djgpp > distribution. If the C++ library comes with it, it should be > $DJDIR/lang/cxx/_G_config.h I explained it above, where cpp will search the headers, and $(DJDIR)/djgpp/include is one of them (in gcc terms it is the TOOL_INCLUDE_DIR). BTW: I have configured now gcc to have in the directory names "djgpp" instead of "i386-pc-msdosdjgpp". > Why not just leave it in lgp*b.zip? People are used to downloading it > anyway, and it includes all the other C++ libraries. Because first of the different copying police between libstdc++ and libg++ and second, because it often possible to compile and link C++ programs without libg++ but not without libstdc++ > Yes. People expect libgpp.a and the documentation (and faqs) talk OK, I will leave it libgpp.a > about libgpp.a. The gxx.exe helper in djgpp uses -lgpp. Why change BTW: I will include gpp280b.zip the original gxx.exe, or shouldn't I? > it? Unix uses libg++.a, so it's not like we're being "more > compatible". I made it only, since we have already libstdcxx.a (from libstdc++.a). > > And BTW: I will configure gcc (or better cpp) to have $DJDIR/include/gxx > > as default directories for C++ headers and not $DJDIR/lang/cxx. If this > > will make trouble, please let me know. > > No. Please don't put non-C includes in the C include tree. I don't > want to start getting questions about "hey, why doesn't #include > work for my C program?". Please keep them separate. Ok. > Legally, you must upload the sources. BTW: I meant only for the test version which should be available for the workers. The final distribution will have of course the sources included. Robert -- ****************************************************** * email: Robert Hoehne * * Post: Am Berg 3, D-09573 Dittmannsdorf, Germany * * WWW: http://www.tu-chemnitz.de/~sho/rho * ******************************************************