From owner-freebsd-hackers Sun Dec 18 21:55:47 1994 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id VAA00164 for hackers-outgoing; Sun, 18 Dec 1994 21:55:47 -0800 Received: from saul3.u.washington.edu (root@saul3.u.washington.edu [140.142.83.1]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id VAA00158 for ; Sun, 18 Dec 1994 21:55:45 -0800 Received: by saul3.u.washington.edu (5.65+UW94.10/UW-NDC Revision: 2.32 ) id AA05401; Sun, 18 Dec 94 21:43:03 -0800 X-Sender: spaz@saul3.u.washington.edu Date: Sun, 18 Dec 1994 21:43:02 -0800 (PST) From: John Utz To: Sean Eric Fagan Cc: FreeBSD hackerlist Subject: Is this qualify as a complete and utter hack? Re: any #define experts out there? In-Reply-To: <199412160856.AAA27938@kithrup.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hackers-owner@freebsd.org Precedence: bulk Thanks Sean and Folks!!! The guess Sean makes at the bottom is explicitly correct... On Fri, 16 Dec 1994, Sean Eric Fagan wrote: > >////usr/local/spice3f3/src/lib/dev/mos3//mos3sset.c < /dev/null ...... much mindless compil-o-blather deleted.. > >////usr/local/spice3f3/src/include/spice.h:29: syntax error before `extern' > > It is impossible to say why gcc is behaving the way it appears to without > knowing how "NUMELENS" is referenced. > good point...how come he always nails me on these? :-) > Looking at the error messages above, I'd say that the problem is something > completely different than what you think it is. Thankyou you helpful soul!!! > > Since I do not know what the source code you are trying to compile is, I > cannot help further. The source code was spice3f3. Dan Andersson and I have been whacking away at it for a few weeks now. It is built with one of these nutty convoluted build scripts that seems to make things much harder then it need be, especially since the damn thing will fail in incomprehensible ways if you use any other shell besides bash, which i did not posess until Dan Andersson told me i needed it. Fixing an unfinished header file fixed this error. The program compiled. Upon execution it promptly dumps core. So I sighed, ran util/build clean gcc; Added -g ,Restarted the compile and went to bed ( this takes !!hours!! on a 386 ). Well, after eating up all my swap space..(.16 or 33 megs i forget which) a few times, I got it made with debugging symbols and was pointed to this little wonder: #ifdef HAS_UNIX_SEGMENT_HACK #include #include /* * baseaddr( ) returns the base address of the data segment on most Unix * systems. It's an ugly hack for info that should be provided by the OS. */ /* Does anyone use a pagesize < 256 bytes?? I'll bet not; * too small doesn't hurt */ #define LOG2_PAGESIZE 8 static jmp_buf env; static SIGNAL_TYPE fault( ) { signal(SIGSEGV, (SIGNAL_FUNCTION) fault); /* SysV style */ longjmp(env, 1); } static void * baseaddr( ) { char *low, *high, *at; char *sbrk( ); long x; SIGNAL_TYPE (*orig_signal)( ); if (getenv("SPICE_NO_DATASEG_CHECK") return 0; else ( head for the sphaghetti!!! i was gonna add all this in to the letter, but u guys did not do anything to deserve it... ). So basically, the code that caused the core dump tries to figure out how much memory the system has left, for some reason. Obviously, it breaks alot, so they provided this helpful spot of code to try and make things function, but they did not bother to document it or comment it or anything! Eventually, i should sort this out, but since this is already 1/2way thru break,and i have more, more, more, code to make... ******************************************************************************* John Utz spaz@stein.u.washington.edu idiocy is the impulse function in the convolution of life