On Sun, 7 Jan 2001, Mathieu Bouchard wrote: > > > > And on a Dec Alpha system with gcc -v giving: > > > > Reading specs from > > > > /usr/local/gnu/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/specs > > > > gcc version 2.95.2 19991024 (release) > > > > gcc -g -O2 -ansi main.o dmyext.o libruby.a -lm -o miniruby > > > > ./mkconfig.rb:44: stack level too deep (SystemStackError) > > > Got the same on a NetWinder (StrongARM 233 MHz) yesterday. It looks like > > > it stays stack too deep even though it's at depth 2. Trying: > > My "bodge" for this problem was to change the makefile so that -ansi > > was not used in the CFLAGS. What I should do is this: > > Here it is: > gcc -v > Reading specs from /usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.1/specs > gcc version 2.95.1 19990816 (release) I don't know what changed, but it may be worth you upgrading. "GCC 2.95.2 is the current release and we are currently working on GCC 2.95.3, a maintainance update. GCC 2.96 and 2.97 are development snapshots leading towards GCC 3.0 which we hope to release by the end of Q1 2001." to quote from: http://gcc.gnu.org/index.html > > and dig this: there is no -ansi during compilation, but the stack problem > is there. OK, well my bodge was, quite simply, a stab in the dark. I have never neded that option before, so it seemed worth trying to remove it. > > I patched eval.c so that it gives me some info about the involved values: > It may be useful for the developers if you express these to these as patches, (using gnu diff: $ diff -u oldfile newfile for those wondering how.:-)) > sprintf(foo, > "too deep: stack_length(0)=%d, STACK_LEVEL_MAX=%d", > stack_length(0),STACK_LEVEL_MAX); > > ./mkconfig.rb:44: too deep: > stack_length(0)=157736579, > STACK_LEVEL_MAX=1835008 (SystemStackError) > > this seems like little too high a value. > > gdb miniruby > run -Cext extmk.rb > > print rb_gc_stack_start #=> (VALUE *) 0xe24cb004 > > added a printf for __builtin_frame_address(0) > > #=> 0xbfffb998 > > for some reason, in gc.c, in Init_stack(), > __builtin_frame_address(2) gives a value like 0xe24cb004 (???) > > well that's all I'm trying for now. I know very little about this > architecture and stack issues. I think I'm stuck too. :-) > > matju > Hugh hgs / dmu.ac.uk