>>>>> "TG" == Thomas Graichen <graichen@rzpd.de> writes:

TG> maybe the 4 shlib problem is due to the following which resulted
TG> in the same behaviour on OpenBSD/pmax:

TG> ---
TG> CVSROOT:        /cvs
TG> Module name:    src
TG> Changes by:     pefo@cvs.openbsd.org    97/02/12 15:49:33

TG> Modified files:
TG>         gnu/usr.bin/binutils/ld/scripttempl: elfmips.sc 

TG> Log message:
TG> Don't space text/data in shared libs by 256Mb. ld.so can't handle it
TG> with the shm sizing method it uses for the moment, so loading many
TG> shlibs effectively makes a proram run out of VM.
TG> ---

TG> don't know if it's the same for NetBSD/pmax

This certainly looks like it's the same problem.  ldd is running out
of memory trying to mmap() the shared libraries, which *do* have a
~256MB hole between the .text and .data segments, according to
objdump.  It looks like the built in link script for shared libraries
is at fault (though I'm not certain because I lack source to the
version of gld used currently in NetBSD/pmax):

GNU ld version cygnus-2.7.1 (with BFD cygnus-2.7.2)
  Supported emulations:
   elf32lmip
using internal linker script:
==================================================
OUTPUT_FORMAT("elf32-littlemips", "elf32-bigmips",
	      "elf32-littlemips")
%%%%%%%%%% stuff deleted %%%%%%%%%%
  . += 0x10000000 - 0x0400000;
  . += 0x10000;
  .data    :
  {
    _fdata = . ;
    *(.data)
    *(.gnu.linkonce.d*)
    CONSTRUCTORS
  }
%%%%%%%%%% etc. %%%%%%%%%%

Attempting to use the link script from stock binutils-2.7 seems to not
result in the 256MB hole, but I haven't yet tried building dynamic
programs with the resultant shared libraries.

BTW, does anyone know why none of the link scripts supplied with gld
explicitly arrange the segment list in the ELF program header?  The
info file seems to imply that there is some automatic segment
construction, but I can't seem to find how this is supposed to work.

---Tom