[comp.lang.c] too many enumerated types?

scott@nova.laic.uucp (Scott Weitzenkamp) (02/05/89)

I am having problems getting a 35000 line C program to link on a 
Bell Technologies 386 box running BellTech's System V, Release 3.2.
The 70 source files compiled fine, but here's the error message I
get when I try to link  them:

$ cc -g *.o
ld fatal: fail to write symbol name LESSEQ_OP in string table 
for file a.out

LESSEQ_OP is an enumerated value; we use a lot of enumerated types
in the code.  I have only had this machine for 2 days, and I'm
beginning to really dislike System V UNIX.

What is going on here?  Am I out of room in the symbol table for
all my enumerated values?  Am I going to have to change all
my enums to defines?  If so, that really sucks.  This code runs
fine on BSD-based Unix boxes (Sun3, Sun4, Ultrix).  Have I been
living in Berkeley-land for too long?  What other nasty little
quirks await me?  Is it tougher to port from BSD to System V,
or vice-versa?  I hate dbx, but I think I hate sdb even more.
Is System V Release 4 going to be the big AT&T-Sun merge?  God,
I hope so.

Scott Weitzenkamp           UUCP:  {lll-lcc.arpa,ucbvax}!leadsv!laic!scott
Lockheed AI Center	    ARPA:  farmie@portia.stanford.edu  
"The faster I go, the behinder I get."

Scott Weitzenkamp           UUCP:  {lll-lcc.arpa,ucbvax}!leadsv!laic!scott
Lockheed AI Center	    ARPA:  farmie@portia.stanford.edu  
"The faster I go, the behinder I get."

scott@nova.laic.uucp (Scott Weitzenkamp) (02/05/89)

More info on my link problem: I am compiling all the .c files with
-g, so I guess that accounts for all the extra symbol table info.

Scott Weitzenkamp           UUCP:  {lll-lcc.arpa,ucbvax}!leadsv!laic!scott
Lockheed AI Center	    ARPA:  farmie@portia.stanford.edu  
"The faster I go, the behinder I get."

guy@auspex.UUCP (Guy Harris) (02/06/89)

>What is going on here?  Am I out of room in the symbol table for
>all my enumerated values?

Probably not.  A quick check of the "ld" source reveals that the error
message in question is printed if an "fwrite" of one symbol table entry
fails to return 1.  The most likely causes of this are:

	1) an error from a "write" call in the standard I/O library
	   failing - i.e.:

		you ran out of disk space

	   or

		you overflowed the stupid 1MB default file size limit
		that many S5 implementations use (I guess they're scared
		to up the default to infinitely, or at least some large
		value - hey, guys, it's not in the SVID, AT&T won't yank
		your S5 license if you default it to a huge value, and
		many many many of your customers will probably love you
		for it)

	   or

		you got a real live I/O error

	   or...

	2) a bug in standard I/O in your system.

It definitely has nothing to do with "too many enumerated types"; you're
making a fairly broad assumption by concluding that it's the problem.

My guess would be that it's 1).  If so, there are a variety of
techniques for upping the ulimit; I think in S5R3.2 you can simply
reconfigure your system to set the default higher.  I'd advise that you
set it as high as you can.

>What other nasty little quirks await me?

Hard to say.  There are a variety of other differences; I don't have a
list of all of them handy.

>Is it tougher to port from BSD to System V, or vice-versa?

Hard to say.  It depends on what you're doing.  It's tougher to port
from a system that supports the facilities you use to a system that
doesn't; in some cases vanilla BSD has the facilities and vanilla S5
doesn't, and in other cases vanilla S5 has the facilities and vanilla
BSD does't.

Note that in your case you're not dealing with vanilla BSD, though; both
Ultrix and SunOS have a number of S5 facilities in addition to BSD
facilities.

jas@ernie.Berkeley.EDU (Jim Shankland) (02/06/89)

In article <435@laic.UUCP> scott@nova.laic.uucp (Scott Weitzenkamp) writes:
>
>I am having problems getting a 35000 line C program to link on a 
>Bell Technologies 386 box running BellTech's System V, Release 3.2.
>The 70 source files compiled fine, but here's the error message I
>get when I try to link  them:
>
>$ cc -g *.o
>ld fatal: fail to write symbol name LESSEQ_OP in string table 
>for file a.out

Check your ulimit.  System V imposes a ``soft'' maximum file size --
1 Meg. on the machines I've worked on, maybe less on yours.  You need
to be root to change this limit, on a per-process basis.  Whether this
makes you laugh or cry is up to you.  (Make sure your disk isn't full, also.)

Jim Shankland
jas@ernie.berkeley.edu

"I've been walking in a river all my life, and now my feet are wet"