VBRANDT@DBNUAMA1.BITNET (09/15/88)
I have found what is not quite a bug, but a somewhat annoying feature in the GNU C linker. It seems that the '-s' flag does exactly the opposite of what I think it should do. If you don't specify '-s', the linker appends a symbol table to the executable, if you do specify it, no symbol table is produced. This means that to make executables without symbol tables, one cannot use GCC, but has to invoke everything manually. Also, all the executables from the GNU package themselves have quite big symbol tables. Removing them would save several KB, which might help people suffering from storage/memory shortages. Anyway, thanks to John for his impressive work ! Bitnet: VBRANDT@DBNUAMA1 Volker A. Brandt UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt Angewandte Mathematik ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU (Bonn, West Germany)
leo@philmds.UUCP (Leo de Wit) (09/16/88)
In article <8809150858.AA16391@ucbvax.Berkeley.EDU> VBRANDT@DBNUAMA1.BITNET writes: > > I have found what is not quite a bug, but a somewhat annoying feature in the >GNU C linker. It seems that the '-s' flag does exactly the opposite of what I >think it should do. If you don't specify '-s', the linker appends a symbol >table to the executable, if you do specify it, no symbol table is produced. '-s' does not stand for symbol / no symbol, but for strip. This option is passed to the loader, and means: strip off the symbol table. The default in Unix is to have a symbol table in your executable (so the debuggers are not too bad to work with, although -g is preferred if you want to use dbx). > This means that to make executables without symbol tables, one cannot use >GCC, but has to invoke everything manually. Also, all the executables from >the GNU package themselves have quite big symbol tables. Removing them would >save several KB, which might help people suffering from storage/memory >shortages. I do not quite understand your problem. Put the -s in your makefile, or add -s to CFLAGS. Now you can invoke make with no special parameters. As for removing symbol tables, that's a job for strip(1); no doubt there'll be an ST version soon (if it isn't already there). > Anyway, thanks to John for his impressive work ! I fully agree. Leo.
jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (09/19/88)
From: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU
I have found what is not quite a bug, but a somewhat annoying feature in the
GNU C linker. It seems that the '-s' flag does exactly the opposite of what I
think it should do. If you don't specify '-s', the linker appends a symbol
table to the executable, if you do specify it, no symbol table is produced.
Well, I admit it's somewhat counter-intuitive, but the semantics of -s
is unchanged from what it was in the unhacked LD.C. Ie, the default
behaviour really is supposed to be to produce a symbol table. After
thinking about it, though, it seems reasonable to change it in the ST
version, as the ST format symbol tables are never useful.
This means that to make executables without symbol tables, one cannot use
GCC, but has to invoke everything manually.
That's not true. GCC passes the -s flag along if it's specified. (At
least it's supposed to; did I introduce a bug at the last minute?)
Also, all the executables from
the GNU package themselves have quite big symbol tables. Removing them would
save several KB, which might help people suffering from storage/memory
shortages.
Indeed. I'm pretty sure I built all the executables with -s (to GCC),
so if they've really got symbol tables, perhaps I did leave a bug in
there. I'll investigate tonight and post the results.
Anyway, thanks to John for his impressive work !
You're very welcome.