DS 3100/Xwindows bug

kris graham graham at fuel.dec.com
Tue Nov 28 12:08:45 AEST 1989



In article <7842 at bunny.GTE.COM>, krs0 at GTE.COM (Rod Stephens) writes:
> 
> 
> A guy I work with had a bug in a big Xwindows application on a
> DECstation 3100. At link time he got a few pages of errors like:
> 
> 
> /lib/libX11.a(Xrm.o): jump relocation out-of-range, bad object 
> file produced, can't jump from 0x46c440 to 0x10003970 (index)
> /lib/libX11.a(Xrm.o): jump relocation out-of-range, bad object
> file produced, can't jump from 0x46c47c to 0x10003970 (index)
> 	:
> 	:
> /lib/libc.a(getttyent.o): jump relocation out-of-range, bad object 
> file produced, can't jump from 0x497614 to 0x10003970 (index)
> *** Error code 1
> 
> 
> After an unhelpful call to software support and much fiddling around,
> he narrowed the problem down to a variable named "index". He changed
> the variable's name to something else and all worked fine. It seemed
> as if there might be some C language or system internal variable named
> "index" and that his "index" was getting confused with this one.
> 
> Has anyone else seen this? Does anyone know what was happening?
> 

There could be a 'religious debate' on the proper error handling of a
strict-error-checking  compiler ;-)

This obnoxious error message is documented in the ULTRIX "Release
Notes For RISC Processors" (order # AA-ML77A-TE) ......page 52.

The complier dislikes the idea of mixing system library call names with  
 data structure names!

Here are excerpts from the ULTRIX release notes.

 "If a  global data item is used as if it were a code location
(for example, if a data structure has the same name as a system
call), an error message similar to the following will be printed
at load time"

/lib/libc.a(gethostent.o): jump relocation out-of-range, bad object
file produced, can't jump from 0x4197a0 to 0x1000819 (stat)

If this happens, you should change the name of the data structure
(in this example, it was named 'stat')"

It is not unusual to see a more user-friendly error message in the 
future...although I do not speak for our RISC compiler developers.

Christopher Graham          
Digital Equipment Corp            
Ultrix Resource Center                            
New York City



More information about the Comp.unix.ultrix mailing list