From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108260818.AA15129@clio.rice.edu>
Subject: Re: gcc-3.0.1 WinXP and lfn=n
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 26 Aug 2001 03:18:02 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1010826111036.3978O-100000@is> from "Eli Zaretskii" at Aug 26, 2001 11:15:20 AM
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

> > Hard to say for sure.  I know inside gdb xgcc always made the ntvdm go
> > away on the third one.  The test program usually didn't print anything to
> > the screen, which would indicate the first one.
> 
> Not necessarily: it's possible that the DOS box went away before the 
> display subsystem had a chance to run its redisplay (which only happens 
> once in a while).

Agreed.

> Writing log messages to a disk file, and fsync'ing the handles, might be a 
> more reliable way of tracking the execution.

If it would fail more reliably I'd test that :-)

> > I think we are randomly lucky that the name was 78 characters generated
> > by GCC build instead of 81 ...
> 
> No, that's not luck: function 60h is supposed to take care of this.  
> That's how longish file names work on plain DOS, although we never make 
> sure they are shorter than 80 characters.

Correct.  We are on the hairy edge because we have ../ in paths now.  One
more and we'd be beyond the limit :-)

> > I think we would be better off finding why we get lots of ../ in 3.01 and
> > didn't get any in 2.953 ... just to be safe...
> 
> That's a good thing, too; but we cannot depend on every package doing so: 
> it would make the porter's job impossibly hard.

Understood, but it was working better in 2.953  ... I guess that's progress ...