kevin@kosman.UUCP (Kevin O'Gorman) (12/17/89)
I just tried to make MUSH 7.0.0 with gccc 1.35 on a AT&T 3b1. It made okay, and it can inform me I have no mail just fine, but when I do mush -C -u kevin, I get a memory fault. More later. So I tried compiling with the gcc -traditional swich. Now it won't make because of an "unterminaged #if in glob.c. I can't find what's doing it. The sources were not changed at all between to two makes. So, anybody out there got this to go on a UNIX PC? Should I drop back to (shudder) pcc?
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (12/18/89)
In article <1052@kosman.UUCP> kevin@kosman.UUCP (Root) writes: } I just tried to make MUSH 7.0.0 with gccc 1.35 on a AT&T 3b1. It made } okay, and it can inform me I have no mail just fine, but when I do } mush -C -u kevin, I get a memory fault. More later. 3b1's have a strange memory organization that confuses the xfree() function. This is the function that mush uses to check whether it is about to free() memory that was not malloc()ed. This 3b1 problem was a primary reason why the INTERNAL_MALLOC package was provided back in 6.5.something; try compiling with that definition and see if you get better results. } So I tried compiling with the gcc -traditional swich. Now it won't } make because of an "unterminaged #if in glob.c. I can't find what's } doing it. The sources were not changed at all between to two makes. It's probable that the gcc libraries and header files already provide the BSD-style directory access routines that are compiled into glob.c when BSD is not defined. I don't know if this could cause the problems you describe, but you might try editing glob.c to #if 0 .. #endif all the stuff that is currently surrounded by #ifdef BSD. -- Bart Schaefer "Miserable miscreant! Question MY integrity, will you?" "I have to see some *evidence* of it before I can question it." -- Calvin & Hobbes schaefer@cse.ogi.edu (used to be cse.ogc.edu)