canoaf@ntvax.uucp (Augustine Cano) (07/31/89)
While trying to compile Nethack 3.00 on a 3b1 (67Mb HD/2Mb RAM, 3.51a OS) I got the following: ksh > make cc -O -I../include -c apply.c Assembler: apply.c aline 359 : branch offset is too remote *** Error code 1 Stop. ksh > I read in the documentation that this program was tested on a 3b1. Has anybody else been successful compiling this? Did I miss some setup parameter? I tried to compile and assemble separately using "as -j apply.s -o apply.o": same result. I'll summarize e-mail responses. Thanks in advance. Augustine Cano canoaf@dept.csci.unt.edu
todd@ivucsb.sba.ca.us (Todd Day) (08/01/89)
In article <1989Jul31.033853.23599@ntvax.uucp> canoaf@ntvax.uucp (Augustine Cano) writes:
~While trying to compile Nethack 3.00 on a 3b1 (67Mb HD/2Mb RAM, 3.51a OS)
~I got the following:
~
~ cc -O -I../include -c apply.c
~Assembler: apply.c
~aline 359 : branch offset is too remote
Evidentally, the optimizer is forgetting about how far away some things
are. I got the same problem. Compile as much as you can with the optimizer
(-O flag) and compile the ones that break by hand. In this case,
cc -I../include -c apply.c
Nethack is the only program I've ever had do this. Anyone know why this
happens?djl@dplace.UUCP (Dave Lampe) (08/01/89)
todd@ivucsb.sba.ca.us (Todd Day) writes: >In article <1989Jul31.033853.23599@ntvax.uucp> canoaf@ntvax.uucp (Augustine Cano) writes: ~While trying to compile Nethack 3.00 on a 3b1 (67Mb HD/2Mb RAM, 3.51a OS) ~I got the following: ~ ~ cc -O -I../include -c apply.c ~Assembler: apply.c ~aline 359 : branch offset is too remote >Evidentally, the optimizer is forgetting about how far away some things >are. I got the same problem. Compile as much as you can with the optimizer >(-O flag) and compile the ones that break by hand. In this case, >cc -I../include -c apply.c >Nethack is the only program I've ever had do this. Anyone know why this >happens? I am not sure if it is the reason or not, but on the cc man page int the BUGS section, there is a warning that "The optimizer may produce incorrect code if one asm() routine requires a jump to a label in another asm() routine. The optimizer should be turned off for these code segments." You might also read the -j flag on the as man page for some further explanation. -- Dave Lampe {ames | lll-tis | sun | pyramid}!pacbell!dplace!djl (415) 455-1571 (H) (408) 986-9770 (W) -- Dave Lampe {ames | lll-tis | sun | pyramid}!pacbell!dplace!djl (415) 455-1571 (H) (408) 986-9770 (W)
kevin@kosman.UUCP (Kevin O'Gorman) (08/04/89)
In article <2151@hub.UUCP> todd@ivucsb.sba.ca.us (Todd Day) writes: >In article <1989Jul31.033853.23599@ntvax.uucp> canoaf@ntvax.uucp (Augustine Cano) writes: >~While trying to compile Nethack 3.00 on a 3b1 (67Mb HD/2Mb RAM, 3.51a OS) >~I got the following: >~ >~ cc -O -I../include -c apply.c >~Assembler: apply.c >~aline 359 : branch offset is too remote > >Evidentally, the optimizer is forgetting about how far away some things >are. I got the same problem. Compile as much as you can with the optimizer >(-O flag) and compile the ones that break by hand. In this case, > >cc -I../include -c apply.c > >Nethack is the only program I've ever had do this. Anyone know why this >happens? I think so. The same thing happened to me in compiling the last version of Nethack 2.0. I didn't think to fiddle with -O, but took a good look at what piece of code broke. Anyway, I decided to try undefining the thing that controls whether the compiler is supposed to use bitfields in the struct definitions. When bitfields were no longer being used, everything compiled with -O just fine. This does not explain just what it is that is broken, but it may help explain why the problem shows up so rarely: not many software packages use bitfields, so you won't see this too much.