millerma@dino.cpe.ulowell.edu (Mark Miller) (06/27/91)
In compiling some code, which consists of ~35 seperate modules, with ~45,000 lines of code on one of our DECstation 3100's, I've come up with the following error: ld: eclipse.o: gp relocation out-of-range in .text section for relocation entry 169 for symbol: get_fact_total_age eclipse.o: above gp relocation entry for non .sdata or .sbss symbol All data will fit into the global pointer area Best -G num value to compile all -count'ed objects creating pclips with is 2164 (or greater) 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). make: *** [pclips] Error 1 I've tried changing the -G value, and various other things. I've used lint to try and see if there are any major problems. This code compiles and runs on a Sun and an Apollo. Noone I've tapped here has any more ideas. Does anyone out there? Thanks in advance. Mark ------------------------------------------------------------------------------ | millerma@raven.ulowell.edu or millerma@dragon.ulowell.edu | | Phone: (508) 934-2630 Fax: (508) 458-8289 | ------------------------------------------------------------------------------ -- | millerma@raven.ulowell.edu or millerma@dragon.ulowell.edu | | Phone: (508) 934-2630 Fax: (508) 458-8289 | ------------------------------------------------------------------------------
grr@cbmvax.commodore.com (George Robbins) (06/27/91)
In article <MILLERMA.91Jun27000810@dino.cpe.ulowell.edu> millerma@dino.cpe.ulowell.edu (Mark Miller) writes: > In compiling some code, which consists of ~35 seperate modules, with ~45,000 > lines of code on one of our DECstation 3100's, I've come up with the following > error: > > ld: > eclipse.o: gp relocation out-of-range in .text section for relocation entry 169 for symbol: get_fact_total_age > eclipse.o: above gp relocation entry for non .sdata or .sbss symbol Check that there's no conflict between this name and another procudure or data name, especially one which might be aliased if the assembler/optimzer/linker is truncating externals to less than n-characters (a guess). The mips compiler seems to generate such errors when symbols show up in a different segment than expected. Redefinitions of "end" are a classic example. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
benseb@nic.cerf.net (Booker Bense) (06/30/91)
In article <MILLERMA.91Jun27000810@dino.cpe.ulowell.edu> millerma@dino.cpe.ulowell.edu (Mark Miller) writes: >In compiling some code, which consists of ~35 seperate modules, with ~45,000 >lines of code on one of our DECstation 3100's, I've come up with the following >error: > >ld: >eclipse.o: gp relocation out-of-range in .text section for relocation entry 169 for symbol: get_fact_total_age >eclipse.o: above gp relocation entry for non .sdata or .sbss symbol >All data will fit into the global pointer area >Best -G num value to compile all -count'ed objects >creating pclips with is 2164 (or greater) >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). >make: *** [pclips] Error 1 > >I've tried changing the -G value, and various other things. I've used lint >to try and see if there are any major problems. This code compiles and runs >on a Sun and an Apollo. Noone I've tapped here has any more ideas. Does >anyone out there? Thanks in advance. > -Uhmm, It's been a couple months since I wrestled with this , basically what you have to do is turn off the gp allocation when compiling this your code. As far as I can tell gp allocation is some fast memory scheme for allocating common blocks and external/global variables ( fortran and C words for the same thing). It forces all kinds of restraints on how you organize your common blocks and you have to be alot less sloppy in your code ( i.e. common blocks have to be declared exactly the same everywhere.) This is the fortran standard I believe , but there is almost no large real code in the world that lives up to it. I think the option that works for fortran is : -G0 -static Anyway this solved my problem, now if you ever figuire out how to run a code this large in the debugger let me know %-)! - Booker C. Bense prefered: benseb@grumpy.sdsc.edu "I think it's GOOD that everyone NeXT Mail: benseb@next.sdsc.edu becomes food " - Hobbes