What is gcc -s option?
nospam at mail.invalid
Thu Jan 9 14:19:13 PST 2003
In article <Pine.LNX.4.44.0301091322420.1263-100000 at wlmlfs04.wlmcs.com>,
Bill's LFS Login wrote:
>> How can you forget what you never knew? :-)
> It is a mystical side-effect of the permeation of the ether. You always
> new it, but you didn't know that you new it, which you had forgotten! :P
Works for me........
>> Thanks for clearing that up, was driving more than one of us bonkers.
>> Omit all symbol information from the output file.
>> Now, if I only knew what THAT meant......
Uh oh. He said "briefly" :-)
> Briefly: making a non-interpretative executable involves two major steps.
> Convert the source to an intermediate object format and then find the
> targets of external references made by that object module and create the
> final "executable".
> In static compiles, the "resolutions" are done (from human viewpoint) at
> compile time. All needed code is included in the final "executable" and it
> can run with no services other than those provided by the OS.
> A dynamic executable defers some (or all) of these resolutions until
> run-time. It depends not only on the OS services, but on routines provided
> by shared libraries (DLLs on M$).
> Now, the nub. People write names, not numbers. Machines like numbers not
> names. The numbers the machine likes are (mostly) addresses of one
> form or another and are equated to names that people like
> That is, essentially, what a symbol is - the name that humans use. When
> linking is done statically, all the symbols have been resolved and the
> human-friendly names (contained in a "dictionary") are no longer needed.
> So, we can "strip" them out of the module and substantially reduce the
> module size and load time (the loader doesn't have to read through all
> that trash).
> For dynamic executables, certain symbols are still needed at execute time
> because they depend on symbols that are defined (that is, equated to a
> real address) _at_the_time_of_execution.
> There are alos other types of symbols (for example, those used for
> Now, you can see why it is seldom a good idea to --strip-all on a shared
> library or a dynamically-linked executable (as almost everything in
> chapter 6 becomes).
> However, the --strip-debug is always safe and the --strip-uneeded is
> *usuallly* safe (but be careful - some shared libraries are not always
> correctly detected and needed sysmbols may be erroneously removed. This
> was on 2.2 and 2.4.pre7 kernels and related).
Ineed it does. Will read it again tomorrow so that it really sinks in.
Thanks much, Bill.
Life is the strangest thing I've ever done.
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