Mail Archives: djgpp-workers/1998/02/01/20:45:25
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, <go32.h>
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
> <gxx/string.h> 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 <robert DOT hoehne AT gmx DOT net> *
* Post: Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW: http://www.tu-chemnitz.de/~sho/rho *
******************************************************
- Raw text -