Relocation problems on sparc-unknown-linux with binutils-2.11.90.0.25 and 2.11.90.0.8

[Nix]

With a system built with gcc-2.95.4pre+dso-handle-patch as of 2001-08-10,
and glibc from CVS as of 2001-08-14, linking perl yields this:

gcc -o libperl.so -shared perl.o  gv.o toke.o perly.o op.o regcomp.o dump.o 
util.o mg.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o 
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o 
perlapi.o 
sv.o: In function `Perl_sv_rvweaken':
sv.o(.text+0x6d04): relocation truncated to fit: R_SPARC_GOT13 LLC62
sv.o(.text+0x6da4): relocation truncated to fit: R_SPARC_GOT13 LLC63
[snip ~1000 lines of such errors, all overflows of R_SPARC_GOT13]
perlio.o: In function `PerlIO_vsprintf':
perlio.o(.text+0x78): relocation truncated to fit: R_SPARC_GOT13 LLC2
collect2: ld returned 1 exit status
make: *** [libperl.so] Error 1

(and so on for all R_SPARC_GOT13 relocations.)

Compilation was with the flags

-O2 -m32 -pipe -D__NO_STRING_INLINES -D_FILE_OFFSET_BITS=64

and the problem way well happen with none at all.

I, at least, would not expect these relocations to overflow:

0000000000006d04 R_SPARC_GOT13     .LLC62
0000000000006da4 R_SPARC_GOT13     .LLC63

(The same problem happens with binutils-2.11.90.0.8, so it is probably
not related to the recent Sparc relocation changes. Probably, it is my
fault; I seem to have been making every mistake in the book in building
this toolchain :(( )

(I'm not subscribed to this list, so please Cc the flames saying how any
fool should know that this isn't a binutils bug at all but rather a bug
(that has been known about for decades and widely reported in the media)
in {gcc, libc, perl, the hardware, my brain} to me.

Thanks.)

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming