rankin@scubed.com (Tom Rankin) (05/08/91)
I've recently been trying to port a code,
from: Sparcstation running SunOS Release 4.0.3c
to: Decstation running ULTRIX Worksystem V4.1
The code is quite large with many different integrated packages (like
curses, plotting, database, etc.) and utilizes both Fortran and C.
When I attempted to link all the separate pieces of the code together,
I received the following message:
ld:
gp relocation out-of-range errors have occured and bad object file
produced (corrective action must be taken)
Best -G num value to compile all -count'ed objects creating epsat
with is 7
Above best -G num value conservative because of inconsistent
common symbol sizes. Use the -y flag to trace inconsistant common
definitions and then change source to make them consistent
Best -G num value calculation reliable only if all
-count'ed objects were compiled with -G num greater or
equal to maximum size of a literal pool item (8).
*** Error code 1
Stop.
Actually, the object file that is produced *can* be run if you use
chmod to change the permission. However, dbx chokes on this "bad
object file", rendering the object file virtually useless from a
debugging standpoint.
Attempts to compile the code using the suggested -G value were no
more successful. I have also attempted to use the -y <symbol>
option with all of the common block symbols used in my code --
hoping to trace the inconsistent common block that the linker has
accused the code of containing. Unfortunately, the linker reports
no inconsistency in the common block definitions.
Incidentally, I've tried "disconnecting" certain pieces of the code
which have been troublesome, historically. Using this technique, I
have been able to compile a stripped down version of code which
produces an executable, dbx-loadable object (i.e., the linker has no
complaints). I've also been able to isolate a single routine that,
when "re-connected", produces the problematic linker output shown
above. I've carefully examined all of the common blocks (across
several include files), performed cross-reference checks, and cannot
locate any symbol clashes or definitional inconsistencies.
Is there any diagnostic which I can use to track down the actual
inconsistency when the linker detects it? I am at something of a
loss on how to proceed at the point. Can anyone proffer any
suggestions?
I will be watching the cross-posted newsgroups for a response, but
I'd appreciate direct e-mail, if possible.
Thanks much,
TR
--------------------------------------------------------------------------
Tom Rankin Maxwell Laboratories, S-CUBED Division 3398 Carmel Mtn Rd.
rankin@scubed.scubed.com (619) 587-8394 San Diego, CA 92121
--------------------------------------------------------------------------
--
--------------------------------------------------------------------------
Tom Rankin Maxwell Laboratories, S-CUBED Division 3398 Carmel Mtn Rd.
rankin@scubed.scubed.com (619) 587-8394 San Diego, CA 92121
--------------------------------------------------------------------------jbryans@beach.csulb.edu (Jack Bryans) (05/09/91)
I had similar gp relocation problems trying to make ucbMail. The make file used xstr to gather strings together, and the combination of xstr, mips cc, & ld didn't seem to get along at all. Finally got a make by using cc for the pre-processing "cc -E"'s (-U__STDC__ helped a lot, too), and gcc for the "cc . . . x.c"'s. Not a whimper from the loader, and no mucking about w/-G's. I'm curious what experience others have had w/xstr and the mips compiler. Jack