Xref: utzoo comp.unix.sysv386:5980 comp.lang.c++:12223
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!uunet!pcserver2!ddsw1!nvk
From: nvk@ddsw1.MCS.COM (Norman Kohn)
Newsgroups: comp.unix.sysv386,comp.lang.c++
Subject: Re: problems linking large files
Keywords: ld
Message-ID: <1991Mar14.140433.4397@ddsw1.MCS.COM>
Date: 14 Mar 91 14:04:33 GMT
References: <815@metoch.uu.ch>
Organization: ddsw1.MCS.COM Contributor, Wheeling, IL
Lines: 30

In article <815@metoch.uu.ch> brunner@metoch.uu.ch (felix brunner) writes:
>I have some problems with ld (linker of C++, C resp.)!
>I am using Interactive Unix 2.2 and Glockenspiel C++ 2.0B.
>
>ld displays the following error message:
>	fail to write symbol name 'symbol_name' in string table
>	for file 'file_name'


I have encountered this with two versions of ld (ISC and UPORT)
on a large software package.  I concluded that the problem was
the number of externs in my software:  I successfully corrected
it by taking large numbers of related storage and combining
them into structs... i.e.,
	int a,b;
became
	struct {int a,b;}foo;
so that references became foo.a and foo.b.
Now a and b are defined offsets and the only extern is foo.

I readily acknowledge that this should not help:  a properly written
linker should size its tables and files dynamically, and such large
packages as emacs and gcc compile and link without trouble.
I have not compared symbol table sizes.  But the fix works,
and I've left well enough alone.

-- 
Norman Kohn   		| ...ddsw1!nvk
Chicago, Il.		| days/ans svc: (312) 650-6840
			| eves: (312) 373-0564