shevett@labii.UUCP (Dave Shevett) (07/31/89)
Ok - I get all set up "Gee! Nethack 3.0! And LOOK! It'll run on my little ol 7300. How sweet." Many edits, shars, and tinkers later, I get the following compiler error: cc -O -I../include -c apply.c Assember: apply.c aline 359 : branch offset is too remote *** Error code 1 Stop Grrr. I can handle normal errors - this one threw me. Not knowing 'c' beyond the 'hello world' stage, I dropped the whole shebang and shelved it until I could run up Pnews. Here's the config: 3b1 w/1.5 meg Ram, 67 meg drv, 3.5 OS. Config.h shows: #define UNIX /* delete if no fork(), exec() available */ #define STUPID /* avoid some complicated expressions if #define STUPID_CPP /* use many small functions instead of macros to Somewhere it said to define STUPID_CPP - in unixconf.h? #define SYSV /* define for System V */ #define UNIXPC /* use in addition to SYSV for AT&T 7300/3B1 */ /* also note that the stock cpp qualifies as a STUPID_CPP for config.h */ Yah - thats where it was - Am I missing something goofy here? Has anyone else had hassles running up on the 3b1? /--------------------+ 'The shortest distance +------------------\ | Dave Shevett | between two puns is a | Labyrinth II BBS | | shevett@labii.UUCP | straight line...' | W. Trenton, NJ | \--------------------+ - Doc Webster +------------------/
miket@astro.UMD.EDU (Mike Tripicco) (07/31/89)
In article <217@labii.UUCP> shevett@labii.UUCP (Dave Shevett) writes: > >Many edits, shars, and tinkers later, I get the following compiler error: > > cc -O -I../include -c apply.c >Assember: apply.c >aline 359 : branch offset is too remote >*** Error code 1 >Stop >Here's the config: 3b1 w/1.5 meg Ram, 67 meg drv, 3.5 OS. > This problem also occurred for earlier versions of nethack on my 3b1, so I was ready for it when it happened here--the optimizer evidently generates bad code in a couple of cases. I think it happens only for apply.c and read.c--just wait for the error and retype the offending compile line *without* invoking the optimizer: cc -I../include -c apply.c and when this finishes, just type "make" again. Simple as that. I did have one unpleasant experience with nh3.0 on my 3b1 though; I got the dreaded memory fault---the error message was something like: monsndx--error indexing monster (f0000) The game crashed, and a save file was created. However I can't get it to restart that game. I'm worried because this happened the first (and only) time I reached Dlvl 5--I hope it won't happen *every* time! Anyone know any more about this? MikeT (miket@astro.umd.edu)
kevin@kosman.UUCP (Kevin O'Gorman) (08/01/89)
In article <217@labii.UUCP> shevett@labii.UUCP (Dave Shevett) writes: >Ok - I get all set up "Gee! Nethack 3.0! And LOOK! It'll run on my >little ol 7300. How sweet." > >Many edits, shars, and tinkers later, I get the following compiler error: > > cc -O -I../include -c apply.c >Assember: apply.c >aline 359 : branch offset is too remote >*** Error code 1 >Stop Yeah. Stop. I deleted the rest of the message, but you're using the stock cc, right? You've also got a configuration switch defined in there somewhere that turns on the use of bitfields to make structs more compact. The problem is that in this configuration, cc generates short branch instructions for parts of 'if' commands, when it cannot really tell that a short branch will get there. You have two solutions: turn off bitfields, or turn to gcc. Enjoy.
rjd@occrsh.ATT.COM (Randy_Davis) (08/02/89)
In article <217@labii.UUCP> shevett@labii.UUCP (Dave Shevett) writes: |[....] |#define STUPID /* avoid some complicated expressions if |#define STUPID_CPP /* use many small functions instead of macros to | |Somewhere it said to define STUPID_CPP - in unixconf.h? | |#define SYSV /* define for System V */ |#define UNIXPC /* use in addition to SYSV for AT&T 7300/3B1 */ | /* also note that the stock cpp qualifies as a | STUPID_CPP for config.h */ I ran into something I was not expecting.... When comiling the same module Dave had troubles with (apply.c), the make croaked with a "rm.h: Too many defines" about 100 times followed by the same message for hack.h. This is on a 3B2 model 700 running 16 Meg Ram and the 4.2 C compiler and a ulimit of 2^16. I was quite surprised to determine that the C-preprocessor on THIS machine qualified as a "STUPID_CPP", but defining that define allowed it to compile. Of course, now it is "Memory faulting" after picking the character class whether you or it does it, so I am now putting some tracing prints in the code so I can find the offending statements. Can anyone who has delt with the Memory Fault after picking the character class save me some time on this bug? (Email preferable for speed sake, feel free to also post). Randy Davis UUCP: ...(att!)ocrjd!randy, randy@ocrjd.att.com ...(att!)occrsh!rjd, rjd@occrsh.att.com
rjd@occrsh.ATT.COM (Randy_Davis) (08/03/89)
In article <824@occrsh.ATT.COM> rjd@occrsh.UUCP (Randy_Davis) writes: | Of course, now it is "Memory faulting" after picking the character class |whether you or it does it, so I am now putting some tracing prints in the |code so I can find the offending statements. | | Can anyone who has delt with the Memory Fault after picking the character |class save me some time on this bug? (Email preferable for speed sake, feel |free to also post). Hold the presses.... I found the fix to the problem I pose above. It turns out (20 compiles later and putting in LOTS of tracing printf's) that I traced it down to the mkroom structure that uses the schar typedef. I *HAD* (honest!!) changed the typedef of schar to short int according to the authors' instructions (running on a 3B2), yet that editing session got hung up on when I was at home and got a phone call (ain't call-waiting a pain sometimes?). I had forgotten it and missed re-doing it... So.. NOW nethack is working until I find a bug in the actual operation of it. Thanks anyway, Randy Davis UUCP: ...(att!)ocrjd!randy, randy@ocrjd.att.com ...(att!)occrsh!rjd, rjd@occrsh.att.com