Message-Id: <200006061748.UAA20575@alpha.netvision.net.il> Date: Tue, 06 Jun 2000 20:47:47 +0200 X-Mailer: Emacs 20.6 (via feedmail 8.1.emacs20_6 I) and Blat ver 1.8.5b From: "Eli Zaretskii" To: Laurynas Biveinis CC: djgpp-workers AT delorie DOT com In-reply-to: <393BE1CA.B06CAC0F@softhome.net> (message from Laurynas Biveinis on Mon, 05 Jun 2000 20:22:18 +0300) Subject: Re: Testers wanted: a fix for GCC header problem References: <3939239A DOT 18870 DOT 336AAF AT localhost> <393BE1CA DOT B06CAC0F AT softhome DOT net> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Mon, 05 Jun 2000 20:22:18 +0300 > From: Laurynas Biveinis > > In file included from ../../gcc/tsystem.h:52, > from ../../gcc/libgcc2.c:37: > d:/djgpp/include/stdio.h:35: warning: redefinition of `va_list' > include/stdarg.h:112: warning: `va_list' previously declared here > d:/djgpp/include/stdio.h:38: warning: redefinition of `size_t' > include/stddef.h:200: warning: `size_t' previously declared here > In file included from ../../gcc/tsystem.h:69, > from ../../gcc/libgcc2.c:37: > d:/djgpp/include/stdlib.h:39: warning: redefinition of `wchar_t' > include/stddef.h:288: warning: `wchar_t' previously declared here Yep, known problems. If you search the mail archives, you will find these popping up time and again, since the GCC maintainers took their attitude. > I'm afraid to make the conclusion that DJGPP headers should reuse GCC > sentinel system. This would be an internal change, so FAQs should > remain minimized. I could take responsibility for making this change > and ensure the absence of problems. I would really like to explore the other solution first: namely, to get the GCC maintainers to refrain from forcing their headers on compliant libraries. It is simply _not right_ for a compiler to force a library to track changes in compiler's configury. A reasonably complaint library should be able to proceed with its development without having to consult the latest GCC CVS tree. It strikes me that the maintainers should re-read what Richard Stallman wrote in the thread about strict-aliasing nuisance: that gratuitously breaking code of compiler's users is not just harsh policy, it's a policy of being harsh! And that a maintainer should adopt a policy of being kind to users, not being harsh.