* linker problem: relocation truncated to fit
@ 2001-09-16 12:17 Petter Reinholdtsen
2001-09-16 16:16 ` H . J . Lu
0 siblings, 1 reply; 20+ messages in thread
From: Petter Reinholdtsen @ 2001-09-16 12:17 UTC (permalink / raw)
To: linux-mips
Hello
I'm using debian/mips (sid) on an SGI Indy with 256 MB RAM. It is as
far as I know up to date with the latest packages.
When I try to compile and link a huge C++ program using Qt and various
other libraries, I get strange error message like this during linking:
libopera.a(registerdialog.o): In function
`RegisterDialog::RegisterDialog(QWidget *, char const *, bool)':
linux/ui/registerdialog.cpp(.text+0xd08): relocation truncated to
fit: R_MIPS_GOT16 RegisterDialog virtual table
libopera.a(registerdialog.o): In function
`RegisterDialog::slotOk(void)':
linux/ui/registerdialog.cpp(.text+0xdd8): relocation truncated to
fit: R_MIPS_CALL16 RegisterWidget::verifySettings(void)
libopera.a(registerdialog.o): In function `onceinalifetime(void)':
regkey/regver.h(.text+0x10d8): relocation truncated to fit:
R_MIPS_CALL16 regkey_init(void)
Is this a known problem, and is there anything I can do to fix it?
% dpkg -l | egrep 'gcc|binutils|g\+\+'
ii binutils 2.11.90.0.31-1 The GNU assembler, linker and binary utiliti
ii g++ 2.95.4-6 The GNU C++ compiler.
ii g++-2.95 2.95.4-0.01090 The GNU C++ compiler.
ii gcc 2.95.4-6 The GNU C compiler.
ii gcc-2.95 2.95.4-0.01090 The GNU C compiler.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: linker problem: relocation truncated to fit
2001-09-16 12:17 linker problem: relocation truncated to fit Petter Reinholdtsen
@ 2001-09-16 16:16 ` H . J . Lu
2001-09-16 16:29 ` Wilbern Cobb
0 siblings, 1 reply; 20+ messages in thread
From: H . J . Lu @ 2001-09-16 16:16 UTC (permalink / raw)
To: Petter Reinholdtsen; +Cc: linux-mips
On Sun, Sep 16, 2001 at 02:17:54PM +0200, Petter Reinholdtsen wrote:
>
> Hello
>
> I'm using debian/mips (sid) on an SGI Indy with 256 MB RAM. It is as
> far as I know up to date with the latest packages.
>
> When I try to compile and link a huge C++ program using Qt and various
> other libraries, I get strange error message like this during linking:
>
> libopera.a(registerdialog.o): In function
> `RegisterDialog::RegisterDialog(QWidget *, char const *, bool)':
> linux/ui/registerdialog.cpp(.text+0xd08): relocation truncated to
> fit: R_MIPS_GOT16 RegisterDialog virtual table
> libopera.a(registerdialog.o): In function
> `RegisterDialog::slotOk(void)':
> linux/ui/registerdialog.cpp(.text+0xdd8): relocation truncated to
> fit: R_MIPS_CALL16 RegisterWidget::verifySettings(void)
> libopera.a(registerdialog.o): In function `onceinalifetime(void)':
> regkey/regver.h(.text+0x10d8): relocation truncated to fit:
> R_MIPS_CALL16 regkey_init(void)
>
This may be a MIPS linker bug/limitation. But I don't use Qt on mips
and have no plan to do so. If you can provide a complete testcase,
in this case, every single file used for the final linking, I will
take a look.
H.J.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 16:16 ` H . J . Lu
@ 2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 16:29 ` Wilbern Cobb
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Wilbern Cobb @ 2001-09-16 16:29 UTC (permalink / raw)
To: H . J . Lu; +Cc: Petter Reinholdtsen, linux-mips
On Sun, 16 Sep 2001, H . J . Lu wrote:
> > libopera.a(registerdialog.o): In function
> > `RegisterDialog::RegisterDialog(QWidget *, char const *, bool)':
> > linux/ui/registerdialog.cpp(.text+0xd08): relocation truncated to
> > fit: R_MIPS_GOT16 RegisterDialog virtual table
> > libopera.a(registerdialog.o): In function
> > `RegisterDialog::slotOk(void)':
> > linux/ui/registerdialog.cpp(.text+0xdd8): relocation truncated to
> > fit: R_MIPS_CALL16 RegisterWidget::verifySettings(void)
> > libopera.a(registerdialog.o): In function `onceinalifetime(void)':
> > regkey/regver.h(.text+0x10d8): relocation truncated to fit:
> > R_MIPS_CALL16 regkey_init(void)
>
> This may be a MIPS linker bug/limitation. But I don't use Qt on mips
This is a `feature' of the MIPS toolchain. Global and static items <= n
bytes are placed into the small data or small bss sections instead of
the normal data or bss sections as an optimization. Excess items would
cause these linker errors.
Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
for most purposes.
-vedge
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: linker problem: relocation truncated to fit
2001-09-16 16:29 ` Wilbern Cobb
@ 2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 22:07 ` Petter Reinholdtsen
2001-09-17 1:50 ` Ralf Baechle
2 siblings, 0 replies; 20+ messages in thread
From: Wilbern Cobb @ 2001-09-16 16:29 UTC (permalink / raw)
To: H . J . Lu; +Cc: Petter Reinholdtsen, linux-mips
On Sun, 16 Sep 2001, H . J . Lu wrote:
> > libopera.a(registerdialog.o): In function
> > `RegisterDialog::RegisterDialog(QWidget *, char const *, bool)':
> > linux/ui/registerdialog.cpp(.text+0xd08): relocation truncated to
> > fit: R_MIPS_GOT16 RegisterDialog virtual table
> > libopera.a(registerdialog.o): In function
> > `RegisterDialog::slotOk(void)':
> > linux/ui/registerdialog.cpp(.text+0xdd8): relocation truncated to
> > fit: R_MIPS_CALL16 RegisterWidget::verifySettings(void)
> > libopera.a(registerdialog.o): In function `onceinalifetime(void)':
> > regkey/regver.h(.text+0x10d8): relocation truncated to fit:
> > R_MIPS_CALL16 regkey_init(void)
>
> This may be a MIPS linker bug/limitation. But I don't use Qt on mips
This is a `feature' of the MIPS toolchain. Global and static items <= n
bytes are placed into the small data or small bss sections instead of
the normal data or bss sections as an optimization. Excess items would
cause these linker errors.
Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
for most purposes.
-vedge
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 16:29 ` Wilbern Cobb
@ 2001-09-16 22:07 ` Petter Reinholdtsen
2001-09-16 22:38 ` Ryan Murray
2001-09-16 22:50 ` Wilbern Cobb
2001-09-17 1:50 ` Ralf Baechle
2 siblings, 2 replies; 20+ messages in thread
From: Petter Reinholdtsen @ 2001-09-16 22:07 UTC (permalink / raw)
To: linux-mips
[Wilbern Cobb]
> This is a `feature' of the MIPS toolchain. Global and static items <= n
> bytes are placed into the small data or small bss sections instead of
> the normal data or bss sections as an optimization. Excess items would
> cause these linker errors.
>
> Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> for most purposes.
I tried -G4, -G2 and -G1 without any luck. Even with -G1 there are still
more than 9300 relocation messages. (Do I need to compile all the object
files again, by the way? I've only tried to relink -- it takes 12 hours
to compile :-( ))
Unfortunately, my problem is with is a prorietary software product
(Opera web browser), so I can not send you any source or object files.
:-(
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 22:07 ` Petter Reinholdtsen
@ 2001-09-16 22:38 ` Ryan Murray
2001-09-16 22:50 ` H . J . Lu
2001-09-16 22:50 ` Wilbern Cobb
1 sibling, 1 reply; 20+ messages in thread
From: Ryan Murray @ 2001-09-16 22:38 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Mon, Sep 17, 2001 at 12:07:19AM +0200, Petter Reinholdtsen wrote:
> [Wilbern Cobb]
> > This is a `feature' of the MIPS toolchain. Global and static items <= n
> > bytes are placed into the small data or small bss sections instead of
> > the normal data or bss sections as an optimization. Excess items would
> > cause these linker errors.
> >
> > Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> > for most purposes.
>
> I tried -G4, -G2 and -G1 without any luck. Even with -G1 there are still
I don't think -G is the problem here. The problem is that the GOT
needs to be bigger than a 16 bit value. The only way to do this is to
recompile everything that is going to be linked in statically
(libc_noshared.a and libgcc.a included) with -Wa,-xgot This problem
currently affects openh323 and mozilla, among other things.
--
Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org)
The opinions expressed here are my own.
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 22:38 ` Ryan Murray
@ 2001-09-16 22:50 ` H . J . Lu
2001-09-17 1:55 ` Ralf Baechle
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: H . J . Lu @ 2001-09-16 22:50 UTC (permalink / raw)
To: Ryan Murray; +Cc: linux-mips, binutils, gcc
On Sun, Sep 16, 2001 at 03:38:57PM -0700, Ryan Murray wrote:
> On Mon, Sep 17, 2001 at 12:07:19AM +0200, Petter Reinholdtsen wrote:
> > [Wilbern Cobb]
> > > This is a `feature' of the MIPS toolchain. Global and static items <= n
> > > bytes are placed into the small data or small bss sections instead of
> > > the normal data or bss sections as an optimization. Excess items would
> > > cause these linker errors.
> > >
> > > Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> > > for most purposes.
> >
> > I tried -G4, -G2 and -G1 without any luck. Even with -G1 there are still
>
> I don't think -G is the problem here. The problem is that the GOT
> needs to be bigger than a 16 bit value. The only way to do this is to
> recompile everything that is going to be linked in statically
> (libc_noshared.a and libgcc.a included) with -Wa,-xgot This problem
> currently affects openh323 and mozilla, among other things.
>
I don't think mips is the only platform which has this problem. Do
Alpha, PowerPC and Sparc have similar problems like that? What are
the solutions for them?
BTW, it sounds like the -fpic vs. -fPIC issue.
H.J.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: linker problem: relocation truncated to fit
2001-09-16 22:50 ` H . J . Lu
@ 2001-09-17 1:55 ` Ralf Baechle
2001-09-17 22:40 ` Richard Henderson
2001-09-17 22:47 ` Richard Henderson
2001-09-26 10:08 ` Erik Corry
2 siblings, 1 reply; 20+ messages in thread
From: Ralf Baechle @ 2001-09-17 1:55 UTC (permalink / raw)
To: H . J . Lu; +Cc: Ryan Murray, linux-mips, binutils, gcc
On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> I don't think mips is the only platform which has this problem. Do
> Alpha, PowerPC and Sparc have similar problems like that? What are
> the solutions for them?
>
> BTW, it sounds like the -fpic vs. -fPIC issue.
It is. Yet I wouldn't like to assign a different meaning to -fpic and
-fPIC as most makefiles make little difference between these two options,
so that would imply quite some overhead.
Ralf
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 1:55 ` Ralf Baechle
@ 2001-09-17 22:40 ` Richard Henderson
2001-09-17 22:53 ` H . J . Lu
0 siblings, 1 reply; 20+ messages in thread
From: Richard Henderson @ 2001-09-17 22:40 UTC (permalink / raw)
To: Ralf Baechle; +Cc: H . J . Lu, Ryan Murray, linux-mips, binutils, gcc
On Mon, Sep 17, 2001 at 03:55:09AM +0200, Ralf Baechle wrote:
> It is. Yet I wouldn't like to assign a different meaning to -fpic and
> -fPIC as most makefiles make little difference between these two options,
> so that would imply quite some overhead.
There is already such a difference. Sparc uses 13-bit GOT offsets
with -fpic and 32-bit offsets with -fPIC. I'm considering changes
to Alpha to use a 16/32 split for pic/PIC.
r~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 22:40 ` Richard Henderson
@ 2001-09-17 22:53 ` H . J . Lu
2001-09-17 22:56 ` Richard Henderson
2001-09-17 23:01 ` Jakub Jelinek
0 siblings, 2 replies; 20+ messages in thread
From: H . J . Lu @ 2001-09-17 22:53 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ralf Baechle, Ryan Murray, linux-mips, binutils, gcc
On Mon, Sep 17, 2001 at 03:40:01PM -0700, Richard Henderson wrote:
> On Mon, Sep 17, 2001 at 03:55:09AM +0200, Ralf Baechle wrote:
> > It is. Yet I wouldn't like to assign a different meaning to -fpic and
> > -fPIC as most makefiles make little difference between these two options,
> > so that would imply quite some overhead.
>
> There is already such a difference. Sparc uses 13-bit GOT offsets
> with -fpic and 32-bit offsets with -fPIC. I'm considering changes
> to Alpha to use a 16/32 split for pic/PIC.
Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?
H.J.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 22:53 ` H . J . Lu
@ 2001-09-17 22:56 ` Richard Henderson
2001-09-17 23:06 ` H . J . Lu
2001-09-17 23:01 ` Jakub Jelinek
1 sibling, 1 reply; 20+ messages in thread
From: Richard Henderson @ 2001-09-17 22:56 UTC (permalink / raw)
To: H . J . Lu; +Cc: Ralf Baechle, Ryan Murray, linux-mips, binutils, gcc
On Mon, Sep 17, 2001 at 03:53:25PM -0700, H . J . Lu wrote:
> Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?
Yes, but of course the total GOT/small data area is constrained
by the size allowed by -fpic.
r~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 22:56 ` Richard Henderson
@ 2001-09-17 23:06 ` H . J . Lu
0 siblings, 0 replies; 20+ messages in thread
From: H . J . Lu @ 2001-09-17 23:06 UTC (permalink / raw)
To: Richard Henderson; +Cc: Ralf Baechle, Ryan Murray, linux-mips, binutils, gcc
On Mon, Sep 17, 2001 at 03:56:16PM -0700, Richard Henderson wrote:
> On Mon, Sep 17, 2001 at 03:53:25PM -0700, H . J . Lu wrote:
> > Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?
>
> Yes, but of course the total GOT/small data area is constrained
> by the size allowed by -fpic.
It doesn't help much if you do need -fPIC on some Qt code. Since I
don't use Qt on mips, I will let others work on it.
H.J.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 22:53 ` H . J . Lu
2001-09-17 22:56 ` Richard Henderson
@ 2001-09-17 23:01 ` Jakub Jelinek
1 sibling, 0 replies; 20+ messages in thread
From: Jakub Jelinek @ 2001-09-17 23:01 UTC (permalink / raw)
To: H . J . Lu
Cc: Richard Henderson, Ralf Baechle, Ryan Murray, linux-mips,
binutils, gcc
On Mon, Sep 17, 2001 at 03:53:25PM -0700, H . J . Lu wrote:
> Can you mix object files compiled with -fPIC/-fpic on Sparc/Alpha?
At least on the Sparc, you can mix them as you want, if you don't
overflow the signed 13bit relocs in -fpic objects. The linker will tell
you...
Jakub
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 22:50 ` H . J . Lu
2001-09-17 1:55 ` Ralf Baechle
@ 2001-09-17 22:47 ` Richard Henderson
2001-09-17 22:56 ` Jakub Jelinek
2001-09-20 22:52 ` Geoff Keating
2001-09-26 10:08 ` Erik Corry
2 siblings, 2 replies; 20+ messages in thread
From: Richard Henderson @ 2001-09-17 22:47 UTC (permalink / raw)
To: H . J . Lu; +Cc: Ryan Murray, linux-mips, binutils, gcc
On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> I don't think mips is the only platform which has this problem. Do
> Alpha, PowerPC and Sparc have similar problems like that? What are
> the solutions for them?
Alpha has a complicated scheme by which every input object file may
be assigned to a different GOT, each of which is limited to 64k. The
other reason this works is that variables assigned to .sdata/.sbss
are _not_ treated differently wrt code generation. Instead, this is
optimized via linker relaxation.
IA-64 will overflow its small data area at 22 bits.
PowerPC and Sparc do not use .sdata/.sbss.
r~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 22:47 ` Richard Henderson
@ 2001-09-17 22:56 ` Jakub Jelinek
2001-09-20 22:52 ` Geoff Keating
1 sibling, 0 replies; 20+ messages in thread
From: Jakub Jelinek @ 2001-09-17 22:56 UTC (permalink / raw)
To: Richard Henderson, H . J . Lu, Ryan Murray, linux-mips, binutils,
gcc
On Mon, Sep 17, 2001 at 03:47:54PM -0700, Richard Henderson wrote:
> PowerPC and Sparc do not use .sdata/.sbss.
Minor correction: PowerPC uses .sdata/.sbss, Sparc does not.
Jakub
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-17 22:47 ` Richard Henderson
2001-09-17 22:56 ` Jakub Jelinek
@ 2001-09-20 22:52 ` Geoff Keating
1 sibling, 0 replies; 20+ messages in thread
From: Geoff Keating @ 2001-09-20 22:52 UTC (permalink / raw)
To: rth; +Cc: hjl, rmurray, linux-mips, binutils, gcc
> Date: Mon, 17 Sep 2001 15:47:54 -0700
> From: Richard Henderson <rth@redhat.com>
> Cc: Ryan Murray <rmurray@cyberhqz.com>, linux-mips@oss.sgi.com,
> binutils@sourceware.cygnus.com, gcc@gcc.gnu.org
> On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> > I don't think mips is the only platform which has this problem. Do
> > Alpha, PowerPC and Sparc have similar problems like that? What are
> > the solutions for them?
>
> Alpha has a complicated scheme by which every input object file may
> be assigned to a different GOT, each of which is limited to 64k. The
> other reason this works is that variables assigned to .sdata/.sbss
> are _not_ treated differently wrt code generation. Instead, this is
> optimized via linker relaxation.
>
> IA-64 will overflow its small data area at 22 bits.
>
> PowerPC and Sparc do not use .sdata/.sbss.
Actually, powerpc could use .sdata/.sbss for shared libraries, but it
never got implemented, and it would have the disadvantage that such
code can't be linked into non-shared objects.
It would be a significant speed/space win for certain objects, most
notably libm.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 22:50 ` H . J . Lu
2001-09-17 1:55 ` Ralf Baechle
2001-09-17 22:47 ` Richard Henderson
@ 2001-09-26 10:08 ` Erik Corry
2 siblings, 0 replies; 20+ messages in thread
From: Erik Corry @ 2001-09-26 10:08 UTC (permalink / raw)
To: H . J . Lu; +Cc: Ryan Murray, linux-mips, binutils, gcc
On Sun, Sep 16, 2001 at 03:50:03PM -0700, H . J . Lu wrote:
> >
> > I don't think -G is the problem here. The problem is that the GOT
> > needs to be bigger than a 16 bit value. The only way to do this is to
> > recompile everything that is going to be linked in statically
> > (libc_noshared.a and libgcc.a included) with -Wa,-xgot This problem
> > currently affects openh323 and mozilla, among other things.
I think the current favoured solution on IRIX is multigot, where
if I understand correctly you switch GOT on some function calls
in order to have multiple GOTs in one .o (or .so).
--
Erik Corry erik@arbat.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 22:07 ` Petter Reinholdtsen
2001-09-16 22:38 ` Ryan Murray
@ 2001-09-16 22:50 ` Wilbern Cobb
2001-09-16 22:50 ` Wilbern Cobb
1 sibling, 1 reply; 20+ messages in thread
From: Wilbern Cobb @ 2001-09-16 22:50 UTC (permalink / raw)
To: Petter Reinholdtsen; +Cc: linux-mips
On Mon, 17 Sep 2001, Petter Reinholdtsen wrote:
> [Wilbern Cobb]
> > This is a `feature' of the MIPS toolchain. Global and static items <= n
> > bytes are placed into the small data or small bss sections instead of
> > the normal data or bss sections as an optimization. Excess items would
> > cause these linker errors.
> >
> > Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> > for most purposes.
>
> I tried -G4, -G2 and -G1 without any luck. Even with -G1 there are still
> more than 9300 relocation messages. (Do I need to compile all the object
> files again, by the way? I've only tried to relink -- it takes 12 hours
> to compile :-( ))
>
> Unfortunately, my problem is with is a prorietary software product
> (Opera web browser), so I can not send you any source or object files.
> :-(
You most definately need to recompile all object files, sorry =).
-vedge
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 22:50 ` Wilbern Cobb
@ 2001-09-16 22:50 ` Wilbern Cobb
0 siblings, 0 replies; 20+ messages in thread
From: Wilbern Cobb @ 2001-09-16 22:50 UTC (permalink / raw)
To: Petter Reinholdtsen; +Cc: linux-mips
On Mon, 17 Sep 2001, Petter Reinholdtsen wrote:
> [Wilbern Cobb]
> > This is a `feature' of the MIPS toolchain. Global and static items <= n
> > bytes are placed into the small data or small bss sections instead of
> > the normal data or bss sections as an optimization. Excess items would
> > cause these linker errors.
> >
> > Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> > for most purposes.
>
> I tried -G4, -G2 and -G1 without any luck. Even with -G1 there are still
> more than 9300 relocation messages. (Do I need to compile all the object
> files again, by the way? I've only tried to relink -- it takes 12 hours
> to compile :-( ))
>
> Unfortunately, my problem is with is a prorietary software product
> (Opera web browser), so I can not send you any source or object files.
> :-(
You most definately need to recompile all object files, sorry =).
-vedge
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: linker problem: relocation truncated to fit
2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 22:07 ` Petter Reinholdtsen
@ 2001-09-17 1:50 ` Ralf Baechle
2 siblings, 0 replies; 20+ messages in thread
From: Ralf Baechle @ 2001-09-17 1:50 UTC (permalink / raw)
To: Wilbern Cobb; +Cc: H . J . Lu, Petter Reinholdtsen, linux-mips
On Sun, Sep 16, 2001 at 01:29:38PM -0300, Wilbern Cobb wrote:
> This is a `feature' of the MIPS toolchain. Global and static items <= n
> bytes are placed into the small data or small bss sections instead of
> the normal data or bss sections as an optimization. Excess items would
> cause these linker errors.
>
> Pass the compiler the -Gn flag (default is 8 bytes), ie. -G4 should work
> for most purposes.
Default is -G0 because GP optimization isn't supported with SVR4 PIC code.
SVR4 code uses the $gp register as a pointer to the middle of a 64kbyte
sized data segment called GOT, global offset table. A GOT overflow results
in obscure error messages as you observe them.
The only easy way to get around this is -Wa,-xgot and making sure that all
the static objects like libgcc which can't be rebuilt easily with -Wa,-xgot
get linked in first. More effort is splitting files with this problem into
multiple shared libraries each below the critical size but this usually
results in better code.
The best solution which currently isn't supported by binutils is a multi-got
code model.
Ralf
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2001-09-26 10:08 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-16 12:17 linker problem: relocation truncated to fit Petter Reinholdtsen
2001-09-16 16:16 ` H . J . Lu
2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 16:29 ` Wilbern Cobb
2001-09-16 22:07 ` Petter Reinholdtsen
2001-09-16 22:38 ` Ryan Murray
2001-09-16 22:50 ` H . J . Lu
2001-09-17 1:55 ` Ralf Baechle
2001-09-17 22:40 ` Richard Henderson
2001-09-17 22:53 ` H . J . Lu
2001-09-17 22:56 ` Richard Henderson
2001-09-17 23:06 ` H . J . Lu
2001-09-17 23:01 ` Jakub Jelinek
2001-09-17 22:47 ` Richard Henderson
2001-09-17 22:56 ` Jakub Jelinek
2001-09-20 22:52 ` Geoff Keating
2001-09-26 10:08 ` Erik Corry
2001-09-16 22:50 ` Wilbern Cobb
2001-09-16 22:50 ` Wilbern Cobb
2001-09-17 1:50 ` Ralf Baechle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox