X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Cc: <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Subject: Re: conflicting types for bzero (gcc303)
Date: Wed, 6 Feb 2002 21:30:54 +0100
Message-ID: <000201c1af4d$2d84e030$747d76d5@zastaixp>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <10202061905.AA25442@clio.rice.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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

> > While I was trying to port(compiling) gettext 0.11 I got a 
> warning similar
> > to this one in almost every file:
> 
> Jeff Williams suggested a define in the source to clear up a 
> similar problem
> with bcopy:
> 
> > Don't know if this will help in resolving the issue, but recently
> > I encountered a problem with bcopy when compiling GNU termcap-1.3
> > under djgpp; in termcap.c you'll find:
> > 
> > /* Do this after the include, in case string.h prototypes bcopy.  */
> > #if (defined(HAVE_STRING_H) || defined(STDC_HEADERS)) && 
> !defined(bcopy)
> > #define bcopy(s, d, n) memcpy ((d), (s), (n))
> > #endif

For gettext, another solution is simply to edit the Makefile and remove
the use of -I$DJDIR/include, as that causes gcc to use our stock
stdlib.h
instead of the fixed version it keeps in $DJDIR/lib/gcc-lib/3.x/include.

The root of the problem seems to be the lib-prefix macro used; passing
'--without-libiconv-prefix --without-libintl-prefix' to configure also
solves the problem.

A DJGPP refresh is of course a good thing, but it's not required in this
case.  Furthermore, since the package is effectively overriding gcc's
correct include paths, I'd even consider it a package bug (or more
precisely, a bug in the m4 macros used).

> Or can the prototypes be removed completely with GCC 3.x if they are
> built-in?

Our prototypes are normally not even seen; gcc uses its own stdlib.h
(presumably the result of a fixincludes run).  It's only because gettext
overrides this by specifying -I<prefix>/include that warnings appear.