Date: Tue, 30 May 2000 10:49:44 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp-workers AT delorie DOT com Subject: Re: W2k In-Reply-To: <10005300025.AA14354@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 29 May 2000, Charles Sandmann wrote: > > Well, to test this hypothesis, how about running the full libc build > > under redir? > > No this wouldn't help (just adding redir at the top doesn't fix 3 nestings > below it if they all hook). Did you test it? From your earlier description, I was led to believe that the top-level unhooking does help, since you said: > The nesting 3 level deep sequence: > redir /make /echo2 > seems to be stable > > The nesting 3 level deep sequence: > redir / gcc -c -O2 *.c > seems to be stable Did you mean to say that this works with 3 levels, but crashes with 4, even if `redir' is at the top level? > It looks like we would need a flag to > suppress the hooking (both FPU and Keyboard? just one or the other?) in > something like make (?) which is at the top level and nests alot. I could easily make a variant of Make that does this, but I'm not sure Make alone will solve the problem. In a typical Unix build, you have something like this: make -> make -> bash -> gcc -> cc1 or this: make -> bash -> make -> gcc -> cc1 or even this: make -> bash -> make -> bash -> gcc -> cc1 So perhaps at least Bash should support this option, in order to test it. > The question is - does this get fixed in some service pack? I don't think we had any reports about service packs and their influence on this problem. Perhaps also submit a bug report to Microsoft. Who knows, maybe someone there actually looks at them... ;-)