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.
ignatz@chinet.chi.il.us (Dave Ihnat) (08/04/89)
In article <936@kosman.UUCP> kevin@kosman.UUCP (Root) writes: >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. Er...this has been hashed out in other messages, but as this just arrived, I want to emphasize the answer: It's Not Bitfields; it's the optimizer. Keep your bitfields, and turn on every option your heart desires. But, for every module that generates one of these messages, either manually compile it *without* optimization, or make a dependency in the makefile which does so. Thereafter, all works well with the stock development system. (at least for 3.51; I'd guess for 3.5 as well.) Dave Ihnat ignatz@homebru.chi.il.us (preferred return address) ignatz@chinet.chi.il.us