Date: Wed, 11 Jun 2003 05:46:47 +0300
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <7458-Wed11Jun2003054647+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3EE65932.C87DFF4B@yahoo.com> (message from CBFalconer on Tue, 10
	Jun 2003 18:18:26 -0400)
Subject: Re: DJGPP 2.04 alpha 2 later in the month?
References: <3EE4EB66 DOT DF7891D2 AT phekda DOT freeserve DOT co DOT uk> <3EE4F833 DOT 2B67D8C0 AT yahoo DOT com> <3EE582BB DOT DEC034FA AT yahoo DOT com> <3EE62BC7 DOT F14013F8 AT phekda DOT freeserve DOT co DOT uk> <3EE65932 DOT C87DFF4B AT yahoo DOT com>
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: Tue, 10 Jun 2003 18:18:26 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> > 
> > Try:
> > 
> > gcc @c:/some/path/gcc.opt <other-options>
> 
> That produces a herd of problems, mostly due to the -nostdinc.  I
> see no point to this.

The point is to force the compiler to use the header files from the
source tree, not from your production tree.  In other words, the
library build procedure allows for the setup where you have the
sources installed outside the normal DJGPP directory tree, since the
header files could be different due to development.

Of course, you need to follow -nostdinc switch with another switch,
-I /path/to/include/dir, or else gcc will not find any headers.

> After deleting that what remains is the
> following:
> 
> `-m486' is deprecated. Use `-march=i486' or `-mcpu=i486' instead.
> cc1.exe: warnings being treated as errors
> cc1.exe: warning: -malign-loops is obsolete, use -falign-loops

You should use gcc.opt from the CVS, it should already solve these
warnings.

> nmalloc.c:856: warning: passing arg 1 of `badcallabort' discards
> qualifiers from pointer target type
> nmalloc.c:968: warning: traditional C lacks a separate namespace
> for labels, identifier `exit' conflicts
> 
> I can easily change the name for label exit, but I have no idea
> (see below) how to defeat the arg 1, which is being passed a
> constant string, e.g. badcallabort("fromwhere",9,ptr);

The way to fix it is to change this:

> static void badcallabort(char *msg, int lgh, memblockp m)

Into this:

  static void badcallabort(const char *msg, int lgh, memblockp m)

In other words, the compiler knows that a literal string is a const
char *, so it warns you that badcallabort's prototype didn't promise
it won't modify the object pointed to by `msg'.  Making modifications
to a literal string will have disastrous consequences on your
program's health.