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"