X-Mailer:	exmh version 2.0.2
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	gcc AT gcc DOT gnu DOT org, DJGPP Workers <djgpp-workers AT delorie DOT com>
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
Date:	Mon, 17 Jul 2000 05:25:27 -0600
Message-ID:	<11363.963833127@upchuck>
From:	Jeffrey A Law <law AT cygnus DOT com>
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

- Raw text -