johner@leland.Stanford.EDU (John Lynch) (05/17/91)
I have run into a problem using the cc++ compiler included in release 2.0, and was wondering if anyone has run accross the same thing, or if it is fixed in 2.1. The problem is a known bug in cc++; when it links, sometimes it fails with error: cc++: Internal compiler error. Program collect got fatal signal 11. NextAnswers:objc.629 tells you that: 'You have encountered a known bug in the C++ compiler. The bug has been fixed, and the fix will be in an upcoming release. This is a bug in the program collect that relates to the use of alloca. Essentially, the program collect runs out of stack when "collecting" your application, causing it to crash. There is a workaround. Just increase the stacksize in the shell. Use the limit command to increase your stacksize. Like this: % limit stacksize 10000' OK, so I try that, and sure enough, it links OK. The problem is that now I can't use GDB anymore. If I try to use GDB to debug it, the following occurs (right now the program, "test", just has one main() function): 14 wolverine/Users/johner/Address>gdb test GDB -- NeXT Release 2.0 (v19) -- GNU version 3.1 Copyright (C) 1988 Free Software Foundation, Inc. There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details. GDB is free software and you are welcome to distribute copies of it under certain conditions; type "info copying" to see the conditions. Reading symbol data from test... Reading symbol data from /usr/shlib/libsys_s.B.shlib... Reading Objective-C data... done. Type "help" for a list of commands. (gdb) br main virtual function table field not found Segmentation fault Also, if I limit the stacksize, then recompile,relink, and gdb a program that did not have the fatal error above (i.e. it used to work fine), I get the same problem - so it seems that limiting the stacksize breaks the symbol table generation of the compiler, although it does fix the problem in the collect program. Anyway, has anyone run into this? The "upcoming release" they mention in the NextAnswers, is that 2.1? Does anyone with 2.1 know if this problem is fixed? BTW, I am linking with a debug version of libg++, but I don't think that is the problem, since usually it works fine. Thanks, John Lynch Trilogy Development Group johner@leland.stanford.edu