Mail Archives: djgpp-workers/2000/05/30/09:56:17
> > > 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?
Sure, didn't make a bit of difference (failure in about 2 seconds).
> 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?
each of these only has 2 levels of nesting with hooks. Note that I saw
hook unhooked hooked type nesting also failed.
I can't explain any of this ... for all I know it's some horrid ntvdm
bug based on the box configuration or some timing issue. Won't know
without more testing. I'm not sure if the failures are in the middle
of some image, at the start, or at the exit ...
What's interesting is that sometimes I get the error message, but make
survives and takes a shot at another line or two before getting another
vdm error.
> > 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.
I'm willing to test builds with whatever images you provide. At this
point I'd be happy if any make would work.
> > 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... ;-)
I'll probably do some research and install the SP1 on some W2K system
and give it a try. If it doesn't fix it, I'll get a bug report in on
it. But I think there are still outstanding bugs from my 1993 beta
testing on Win NT 3.1 ... DOS subsystem bugs are not high on the
getting fixed list.
- Raw text -