Re: This is a Cygwin failure yeah?

On 18/01/2009, Dave Korn wrote: > Andy Scott wrote: > > > Again stage3 part of build, and this is what actually stops the build > > the above issue doesn't seem to (I think it happens in stage 2), I get > > the following: > > > > > > > < a few more lines of log deleted :) > > > > > ../../.

Re: This is a Cygwin failure yeah?

2009/1/18 Dave Korn : > Andy Scott wrote: > >> Again stage3 part of build, and this is what actually stops the build >> the above issue doesn't seem to (I think it happens in stage 2), I get >> the following: >> >> > > < a few more lines of log deleted :) > > >> ../../../gcc/libiberty/strsignal.c

Re: This is a Cygwin failure yeah?

Andy Scott wrote: > Again stage3 part of build, and this is what actually stops the build > the above issue doesn't seem to (I think it happens in stage 2), I get > the following: > > < a few more lines of log deleted :) > > ../../../gcc/libiberty/strsignal.c -o strsignal.o > ../../../gcc/libi

Re: Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]

IIRC, that whole clause was because cygwin's dll itself linked with libiberty, so the auto-detect stuff needed an override to make sure the right files were there when you build cygwin1.dll. Otherwise, it would detect that cygwin had strsignal, not build it, then fail later when cygwin1.dll could

Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]

[ DJ Delorie Cc'd in as libiberty maintainer ] Hi DJ, We're having a bit of build trouble for GCC HEAD on Cygwin: to recap, ... > Dave Korn wrote: >> Andy Scott wrote: > >>> ../../../gcc/libiberty/strsignal.c -o strsignal.o >>> ../../../gcc/libiberty/strsignal.c:408: error: conflicting typ

Re: This is a Cygwin failure yeah?

Dave Korn wrote: > Andy Scott wrote: >> ../../../gcc/libiberty/strsignal.c -o strsignal.o >> ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for >> 'strsignal' >> /usr/include/string.h:78: note: previous declaration of 'strsignal' was here >> make[2]: *** [strsignal.o] Error 1 >>

Re: This is a Cygwin failure yeah?

On 10/01/2009, Bernd Roesch wrote: > Hello Dave > >> Unix commad for stack increase(forget the name) > > > > 'ulimit' > > > ah yes i see, I update from time and time and now its more.my bash show this > now.Maybe Andy can do this test what his bash show. > > $ ulimit -a > core file size

Re: This is a Cygwin failure yeah?

Hello Dave On 09.01.09, you wrote: > > You can't assume that actually was a stack overflow just because the > stack ended up corrupted. > yes thats the problem, because a assert give this message too.maybe the program do assert. maybe theres a way that cygwin print out the assert text earlier

Re: This is a Cygwin failure yeah?

Bernd Roesch wrote: > Hello Andy > > On 07.01.09, you wrote: > > >> Cygwin one: >> >> When it gets to stage 3 (after many hours) I get the following printed >> out to the console (not redirected) - >> >> 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error >> while dumping state (p

Re: This is a Cygwin failure yeah?

On 07/01/2009, Dave Korn wrote: > Andy Scott wrote: > > GCC Build One: > > > > Again stage3 part of build, and this is what actually stops the build > > the above issue doesn't seem to (I think it happens in stage 2), > > > That sentence contradicts itself and what you said earlier, doesn't

Re: This is a Cygwin failure yeah?

Andy Scott wrote: > When it gets to stage 3 (after many hours) I get the following printed > out to the console (not redirected) - > > 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error > while dumping state (probably corrupted stack) > > By the looks of this I wold say that som

Re: This is a Cygwin failure yeah?

Hello Andy On 07.01.09, you wrote: > Cygwin one: > > When it gets to stage 3 (after many hours) I get the following printed > out to the console (not redirected) - > > 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error > while dumping state (probably corrupted stack) > I t

Re: This is a Cygwin failure yeah?

Hello Andy On 07.01.09, you wrote: > Cygwin one: > > When it gets to stage 3 (after many hours) I get the following printed > out to the console (not redirected) - > > 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error > while dumping state (probably corrupted stack) > I t

This is a Cygwin failure yeah?

Got to building the latest stuff on Cygwin - I modiifed the autoconfig script to get around some issues relating to 'ln -s' - and I then started the build. Got some errors, one I think is a Cygwin issue (but wanting that final 1% assurance) other I am pretty sure is a build/setup issue: source: