Mail Archives: djgpp-workers/2001/08/21/13:15:22
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.
- Raw text -