> > When linking a big program [with ld -v = 2.5-95q4 (with BFD 2.5-95q4)],
> > I get:
> > 
> > /u/dev/netbsd/libc/sleep.c:39: relocation truncated to fit: LITERALSLEAZY .lita
> > 
> > Can anyone tell me what this means?
> 
> You have too much data living off the GP.  Basically, it (and the
> hundreds of similar messages you probably also saw 8-) is an annoying
> way of saying "don't do that."
> 
> The LITERALSLEAZY relocation is my hack to extend the amount of data
> that can be addressed relative to the GP by the LITERAL relocation by
> 4x.  (LITERAL can address 64k of data relative to the GP,
> LITERALSLEAZY can address 256k, or should be able to.)
> 
> I noticed problems with LITERAL when linking large programs (e.g. some
> gcc modules, or the kernel).  I've never seen the LITERALSLEAZY-hacked
> toolchain run out of GP space.   *sigh*

Arrrgh! So much for building a massively threaded application. So 
much for a you-beaut-64-bit-processor. All that address space, but
only 64k rungs in the ladder to get you there.

I already ran up against this with DEC's OSF/1 linker when I tried
to link just part of this same software for VxWorks/Alpha (which
*must* be linked as a single program). DEC's response was "tough".
There turned out to be a work around in that case - VxWorks can
dynamically load modules and their module handling doesn't suffer
from the same limitation.

> 
> moving to ELF helps this slightly, but there's still a limit in the
> hopefully, that'll be fixed.

Hmm. When will your ELF stuff be available? I feel the need to hack...

Will shared libraries under ELF help me?

> 
> 
> 
> chris
> 

Regards,

-- 
John Birrell                                CIMlogic Pty Ltd
jb@cimlogic.com.au                          119 Cecil Street
Ph  +61  3 9690 6900                        South Melbourne Vic 3205
Fax +61  3 9690 6650                        Australia
Mob +61 18  353  137