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"
scs@adam.pika.mit.edu (Steve Summit) (02/12/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... >...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 In article <955@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >...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: > you ran out of disk space > you overflowed the stupid 1MB default file size limit > or you got a real live I/O error This example shows that the ld in question has violated one of the cardinal rules* of error messages, and also nicely illustrates the importance of these rules. Had ld called perror() or the equivalent**, the real reson for the error would have been immediately evident, and Scott would not have been led to his (reasonable, under the circumstances) misconception about the number of enumerations. Steve Summit scs@adam.pika.mit.edu * Briefly, the rules are: 1. always include the name of the program (ld got this right) 2. for errors related to system calls (including most stdio errors) always call perror 3. for errors that relate to a user file being read, always include the file name and line number ** perror() is less convenient than it could be for printing informative error messages. You could call it with the name of the program, the name of the system call, or the name of the file being read, but not with all three. Here is a simple routine I use to overcome these difficulties. A sample use would be errorp("%s: error writing %s", progname, outfile); Note that errorp is varargs; be sure to declare it as extern void errorp(char *, ...); under an ANSI compiler. Also note that it appends a newline; the format string shouldn't normally include one. #include <stdio.h> #include <stdarg.h> extern int errno; extern char *strerror(); /* VARARGS1 */ void errorp(fmt) char *fmt; { va_list argp; va_start(argp, fmt); vfprintf(stderr, fmt, argp); fprintf(stderr, ": %s\n", strerror(errno)); va_end(argp); } If you don't have an ANSI <stdarg.h>, you'll have to change it slightly to use <varargs.h> (or, failing that, _doprnt). If you don't have strerror(), you can use sys_errlist[].
friedl@vsi.COM (Stephen J. Friedl) (02/12/89)
In article <9218@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes: > > This example shows that the ld in question has violated one of > the cardinal rules* of error messages, and also nicely > illustrates the importance of these rules. > [ * good rules deleted, also mentioning perror(3) ] For you portability fanatics, perror(BA_LIB) is Level 2 in the System V Interface Definition (aka the SVID). `Level 2' means that the feature is not guaranteed to be supported in the SVID beyond three years of the Level 2 date, and in this case, the date is 1/1/1985. Reliable sources tell that perror(3) will still be in the next SVID, but there are `Future Directions' that are much more substantial (they will make the error messages look more like VMS). What does POSIX say about perror(3)? Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for you only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl --------Barbara Bush on... on... No, I just can't do it...--------
john@frog.UUCP (John Woods) (02/14/89)
In article <1049@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > Reliable sources tell that perror(3) will still be in the > next SVID, but there are `Future Directions' that are much more > substantial (they will make the error messages look more like > VMS). I attended a System V Release 4.0 Software Developers' Conference in December, and I can attest that they are definitely making the error messages look like VMS. They showed an example of 5 different current UNIX utilities trying to open an unreadable file, and each gave different one-line complaint, of varying helpfulness. Then they showed an example of The New Wave, a four-line error message which took 3 lines to misdiagnose the problem, and reminded you that this was, in fact, an error. Yup. Just like VMS... :-) -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Presumably this means that it is vital to get the wrong answers quickly. Kernighan and Plauger, The Elements of Programming Style
guy@auspex.UUCP (Guy Harris) (02/18/89)
>Then they showed an example of The New Wave, a four-line error message >which took 3 lines to misdiagnose the problem, and reminded >you that this was, in fact, an error. Fortunately, with any luck, you will at least be able to set an environment variable to cut out most of the more useless stuff from those messages.
decot@hpisod2.HP.COM (Dave Decot) (02/21/89)
> Then they showed an example of The New Wave, a four-line error message > which took 3 lines to misdiagnose the problem, and reminded you that > this was, in fact, an error. Yup. Just like VMS... :-) I object to this use of an HP trademark (NewWave) for something unrelated to our product and for a situation this disgusting. Now, perhaps it is an example of the Open Look... We now return you to your regularly scheduled article. Thank you for your time. :-) Dave
rml@hpfcdc.HP.COM (Bob Lenk) (03/01/89)
In article <1049@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > What does POSIX say about perror(3)? The ANSI C standard includes perror(); it leaves the text of messages implementation-defined. POSIX (1003.1) requires perror() by reference to the ANSI C standard. I think we can expect it to be around for a long time. That doesn't mean that other (possibly better, possibly not) interfaces for printing error messages won't come about, and perhaps even become standard. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com