Date:	Tue, 30 May 2000 10:49:44 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: W2k
In-Reply-To:	<10005300025.AA14354@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1000530104907.905E-100000@is>
MIME-Version:	1.0
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

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... ;-)

- Raw text -