From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108211711.AA13624@clio.rice.edu>
Subject: Re: gcc-3.0.1 and Win2k
To: eliz AT is DOT elta DOT co DOT il
Date: Tue, 21 Aug 2001 12:11:20 -0500 (CDT)
Cc: pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com, acottrel AT ihug DOT com DOT au
In-Reply-To: <2593-Tue21Aug2001195043+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 21, 2001 07:50:43 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

latest implies I looked at the diffs and feel any other changes are either
low risk or good to fix anyway.  I'd like to minimize making custom patches.

Quick proposal:

_rename.c use cvs latest (some case change stuff new)
dpmiexcp.c use cvs latest
crt0.S use cvs latest
open.c - create small patch from 2.03
_open.c - use cvs latest
_creat.c - use cvs latest when committed
_creat_n.c - use cvs latest when committed
utime.c - use cvs latest
fstat.c - patch/merge (several changes due to symlink, etc)
dosexec.c - patch/merge (many changes)

> It's possible that some of the patches are not relevant for GCC, or
> for v2.03 in general.  For example, FAT32 is not supported by v2.03,
> so the change in _open which removed the FAT32 bit from the BX
> register isn't needed.  As another example, if GCC doesn't use fstat
> or utime, the patches we applied there might not be required for
> building it.  In fact, if GCC doesn't use any of the functions that
> call IOCTL, the code in _open which uses the SFN open function is not
> required either.

I'd like to make it available for other packages (non-GCC) also, and
the list above is fairly small.  Only fstat and dosexec are much
effort if we put other not-strictly-required-but-harmless changes in.
For example, can we just leave the fat32 open bits in?

> In general, I'd suggest to patch v2.03 with only those patches which
> we _know_ are required (such as the cure for crashes in nested
> programs), since the patched code is relatively untested and could in
> itself introduce bugs.
> 
> Perhaps we should first have a list of patches, and then have a short
> discussion about which are relevant.  Andris, is it possible to run
> `nm' on the programs which are part of the GCC distribution, to see
> what library functions are linked in?  That might help sorting out the
> patches.