carroll@cis.udel.edu (Mark Carroll) (06/02/91)
Hello all. I'm working on a research project at the U of Delaware, where we're implementing a large package in Objective-C. Underlying the implementation that we're doing is a compiler package called PET, written by NIST in C++. When I compile the PET on the NeXT (using the GNU libraries), I get a segmentation fault on final link phase, during collect. We're running the 2.1 version of the OS, and the 2.0 version of the compilers. Can anyone give me some clue about where collect is segfaulting? Transcript of cc++ -v follows: cc++ -v -w -I/usr/gnu/lib/g++-include -I/usr/gnu/lib/gcc-include -I/usr/in clude -o pet estgram.tab.o def.o type.o const_vars.o mod.o ip.o proc.o stmt.o e xpr.o trans.o EST.o pet.o container.o err.o -lm -lg++ NeXT Release 2.0 (v31.1) -- GNU version 1.36.4 (based on GCC 1.36) /bin/ld -r -o /tmp/cc000711.R -w -lcrt0.o estgram.tab.o def.o type.o const_vars.o mod.o ip.o proc.o stmt.o expr.o trans.o EST.o pet.o container.o err.o -lm -lg++ -lc++ -lsys_s /lib/collect -o /tmp/cc000711.S /tmp/cc000711.R cc++: Internal compiler error. Program collect got fatal signal 11. Anyone with any suggestions, please send mail to carroll@udel.edu. Thanks! <MC> <MC>
das15@cunixa.cc.columbia.edu (Douglas A Scott) (06/02/91)
In article <55250@nigel.ee.udel.edu> carroll@cis.udel.edu (Mark Carroll) writes: >Hello all. > >I'm working on a research project at the U of Delaware, where we're >implementing a large package in Objective-C. Underlying the implementation >that we're doing is a compiler package called PET, written by NIST in C++. > >When I compile the PET on the NeXT (using the GNU libraries), I get a >segmentation fault on final link phase, during collect. I think this one is in NextAnswers. There is a problem with the NeXT make utility in that it will not allow you to set the stacksize limit higher than the default (512K) even if you change it in your current shell. It is this limit that causes the linking stage to bomb--too many symbols for the poor linker to fit into its stack. This is an especially serious problem if you are compiling -g. The solution: first do a "limit stacksize 8192" in your current shell, then execute the final link directly from the shell as a command. What I do is just copy the output that has appeared on the screen from the make and paste it back in as a command. I think perhaps the gnu make that is available as source may not have this problem, but I havent really tested it yet. BTW, sometimes it will bomb out in cc1++ or /bin/ld, too--same problem, same solution. Douglas Scott Columbia University Computer Music Studio Internet: <doug@woof.columbia.edu> <das15@cunixa.cc.columbia.edu> UUCP: ...!columbia!woof!zardoz!doug Phone: (703)765-4771 -----------------------------------------------------------------