What is gcc -s option?
Bill's LFS Login
lfsbill at wlmcs.com
Thu Jan 9 15:33:26 PST 2003
On Fri, 10 Jan 2003, Dan Osterrath wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > BTW, if making object modules *only*, I bet the 'gcc -s' would make those
> > object files non-linkable? IOW, if we tried to just link a bunch of
> > objects together (meaning they are input to the linker a second time)
> > after originally making them with 'gcc -s', I *suspect* they would fail to
> > link properly because of missing but needed (for resolution) symbols.
> Nope. I tried a nm to my libraries and that showed me many symbols. I tried a
> "strip --strip-debug" on a backup of a library and that did not change
> anything with this file. The I tried a "strip --strip-all" won it and it gets
> smaller. A nm did not work anymore.
I thing there would be no debugging symbols unless -G option was passed
when the things are made? Is that the one, '-G'? Anyway, unless debigging
is requested when they are made, there are no debugging symbols.
> Anyone able to test the difference between "gcc -Xlinker -S" and "gcc -s"?
New info. But first, I was speaking of the equivalent of 'gcc -o test
test.c' which makes an object that can be read by a subsequent ggc/ld link
only pass and combined to make an executable (not necessarily a dynamic
one either). This would not apply to shared objects or dynamically linked
executables. Also, '.a' libraries are traditional archives (not shared
objects) consisting of a bunch of object modules (with their symbols) and
often a "directory" at the front which list the symbols found in the
archive and the loctions of the modules in that archive containing those
symbols. It is used to resolve the symbols on the way to making a static
or relocatable executable. These would be more indicative of the effects
of various strip options I think. When making dynamics, things are done
The new info: man gcc says '-s Remove all symbol table and relocation
information from the executable'. So, when OP said -s was not recognized,
it must not have been gcc.
Further, this appears under 'Options for Linking'. This means that
regardless of the text, we would need to do more looking to see what was
actually passed to ld. Gcc could be translating that to Xlinker -S. We (I)
don't know. Also, there is the possibility that what I think of as a
"symbol" may not be a technical "symbol". Example: executable makes a
"reference" to shared_lib.symbol. In the executable, is this a symbol? It
seems to me (human) it is, but to the linker it may be a "reference",
something different than a symbol. In the shared library, I know it is a
symbol that provides the path to resolution of the reference.
Semantics, semantics. Do an nm on a copy of an executable, appropriately I
use a copy of /usr/bin/strip in /tmp, and you get this... (partial)
08061d70 t ieee_variable
080600c0 t ieee_vis_to_flags
0805f150 t ieee_void_type
0805ffc0 t ieee_volatile_type
0805ce60 t ieee_write_2bytes
0805d1d0 t ieee_write_asn
0805d230 t ieee_write_atn65
The I did strip --strip-all and got 'nm: /tmp/strip: no symbols'.
and file /tmp/strip gives
/tmp/strip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
This leads me to believe that there is a "reference" that is not the same
as a "symbol". Because strip is dynamic, and its symbols have been removed
and it can still execute and reference needed shared object "symbols" and
I wish I had the guts (foolishness?) left to 'strip --strip-all' a shared
library on my live system and see what that did to an executable that
lfsbill at wlmcs.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message
More information about the lfs-support