X-Mailer: exmh version 2.0.2 To: Laurynas Biveinis cc: gcc AT gcc DOT gnu DOT org, DJGPP Workers Subject: Re: GCC headers and DJGPP port In-reply-to: Your message of Sun, 16 Jul 2000 16:42:50 +0200. <3971C9EA DOT C2643725 AT softhome DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 05:25:27 -0600 Message-ID: <11363.963833127@upchuck> From: Jeffrey A Law Reply-To: djgpp-workers AT delorie DOT com In message <3971C9EA DOT C2643725 AT softhome DOT net>you write: > For the upcoming GCC 3.0 release, DJGPP team has decided to make GCC > build out-of-box. That would be nice. > One of the major problems requiring addressing is relationship between > following DJGPP and GCC-provided headers: stddef.h, stdarg.h and > varargs.h. The problem is that GCC wants to use and install its > own headers, but it causes type redefinitions, e.g.: > --- > 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:110: warning: `va_list' previously declared here > d:/djgpp/include/stdio.h:38: warning: redefinition of `size_t' > include/stddef.h:199: 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:287: warning: `wchar_t' previously declared here > --- > How would you suggest to fix it? Well, I wouldn't expect it to be significantly different than how this is handled on other platforms. > Currently we see following possible solutions: > 1) Override USER_H and not install those headers for DJGPP. > However, discussion between FreeBSD maintainers and you showed > that you're not going to accept this solution, although we > were unable to find any _technical_ arguments for doing so. > Previously GCC on DJGPP has always worked without installing > its own headers and that's the preferred solution for us, > unless there are serious objections. There are technical arguments in the archives. THe basic and fundamental problem is gcc is designed to work with its headers which implement stuff like varargs or various C++ thingies. Overriding USER_H causes some subset of GCC's header files to not be installed. I've yet to see a case where that's actually the right thing to do (and I'm the person that actually came up with the USER_H override to begin with). If your header files are defining things in the wrong way in the wrong places, then fixincludes is your solution. I would recommend looking into how other systems avoid redefinitions of size_t and friends and do similar things. jeff