Message-ID:	<3971C9EA.C2643725@softhome.net>
Date:	Sun, 16 Jul 2000 16:42:50 +0200
From:	Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer:	Mozilla 4.73 [en] (Win98; U)
X-Accept-Language:	lt,en
MIME-Version:	1.0
To:	gcc AT gcc DOT gnu DOT org
CC:	DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject:	GCC headers and DJGPP port
Reply-To:	djgpp-workers AT delorie DOT com

For the upcoming GCC 3.0 release, DJGPP team has decided to make GCC
build out-of-box. Of course, GCC has been ported there for a long
time. However, the port was not clean due to many reasons - missing
UNIXish features, ports of bash and other programs. Most of those
problems were addressed, but few porting issues still exist. We
would appreciate any help there.

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?
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.

This means that either ours, either yours (or both) headers
should be changed, the question - which ones and how?
Right now we have one internal header which defines macros
which define types, like:
#define __DJ_size_t typedef long unsigned int size_t;
Now in our headers which need size_t we do:
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
This way we prevent multiple redefinitions.

So we could:
2) Add that stuff to GCC headers:
#ifdef __DJGPP__
#include <sys/djtypes.h>
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
#else
typedef ...
#endif
This trick would get DJGPP definitions and this solution is OK
with us, but is it OK with you? It means that DJGPP and your
definitions may differ and this is not good if you wanted to
have common definitions for all systems.

3) The last possible solution is adjusting our headers. While we
admit that our headers are not 100%-ANSI compatible (e.g. stdio.h
defines va_list), it would break backwards compatibility and would 
require DJGPP users to upgrade if they want later GCC version (If 
I understand correctly, one of the arguments for installing your 
headers is that user should not have to update library if he wants 
newer GCC? But in this case it would cause the opposite).
This solution is the worst from the end-user's point of view and
we see it as last resort.

What are your opinions and suggestions?
Thanks in advance,
DJGPP team

- Raw text -