> >I get the same result.  Any ideas what else I can try?
> 
> Run ld under the debugger and find out where it's going wrong?  You may just 
> have discovered a bug in the linker.

Here's what I got using an ld built with CFLAGS=-g for debugging info and
the core from the ld that's in my /usr/bin:

-----------------------------------------------------------------------------
This GDB was configured as "arm--netbsd"...
Core was generated by `ld'.
Program terminated with signal 11, Segmentation fault.
find_solib: Can't read pathname for load map: Input/output error

#0  0x4698 in L317 ()
    at /usr/home/david/netbsd-1.4/usr/src/gnu/usr.bin/ld/ld/ld.c:1345
1345            if (lseek(fd, N_SYMOFF(entry->header) +
entry->starting_offset, L_SET)
(gdb) 
-----------------------------------------------------------------------------

(gdb) bt
#0  0x4698 in L317 ()
    at /usr/home/david/netbsd-1.4/usr/src/gnu/usr.bin/ld/ld/ld.c:1345
#1  0xa7bc in L923 ()
    at /usr/home/david/netbsd-1.4/usr/src/gnu/usr.bin/ld/ld/ld.c:3181

-----------------------------------------------------------------------------

And poking around at various variables didn't really tell me anything
very much.  However, at the "top" of ld.c, there is:

int
main(argc, argv)
	int	argc;
	char	*argv[];
{

	/* Added this to stop ld core-dumping on very large .o files.
*/
#ifdef RLIMIT_STACK
	/* Get rid of any avoidable limit on stack size.  */
	{
		struct rlimit   rlim;

		/* Set the stack limit huge so that alloca does not fail.
*/
		if (getrlimit(RLIMIT_STACK, &rlim) != 0)
			warn("getrlimit");
		else {
			rlim.rlim_cur = rlim.rlim_max;
			if (setrlimit(RLIMIT_STACK, &rlim) != 0)
				warn("setrlimit");
		}
	}
#endif	/* RLIMIT_STACK */

----------------------------------------------------------------------------

However, if I've already done "ulimit -s unlimited", then this piece of
code isn't going to do very much.

Now I remember having a problem with stack hungry programs before, and the
solution was to put "options MAXSSIZ=<a bigger number>" in the kernel
config and build another kernel.  But in this case, it all went horribly
wrong:

options MAXSSIZE="(16*1024*1024)"

which seemed reasonable given that the default is 8Mb, caused a "branch to
never-never land...were dead" error, as soon as init is entered during
boot.  Do I have to do something else to increase the hard limit on stack
size?

Thanks,

David.