Re: Get rid of weak symbols in static objects

[Momchil Velikov <velco at fadata dot bg>]

>>>>> "Ian" == Ian Lance Taylor <ian@wasabisystems.com> writes:

Ian> Momchil Velikov <velco@fadata.bg> writes:
>> >> I find useful to maintain the following invariant:
>> >> 
>> >> "Statically linked executables do not contain undefined symbols
>> >> (unless --noinhibit-exec is given)."
>> 
Ian> Why is that useful?
>> 
>> It roughly useful by the same reasons dead code elimination is
>> useful.

Ian> Well, no.  Dead code elimination saves space in the executable and may
Ian> save space in the instruction cache.  Changing the handle of
Ian> unresolved weak undefined symbols has no comparable effect.

  I do have an application, where undefined weak symbols in static
executables means additional (though not significant) processing
overhead.

>> Besides the generally good idea of being permissive in what
>> you accept, but strict in what you output.

Ian> Well, it does depend upon your definition of what the proper strict
Ian> output is.

  One of the points in my definition is that the output does not
contain useless information (a.k.a. junk).

>> >> From my point of view a weak undefined symbol which never sees a
Ian> definition really is undefined.  The linker resolves it as though it
Ian> has the value zero, but the linker never defines it in the usual
Ian> sense.
>> 
>> IMHO, it defines them exactly in the usual sense -- having a value
>> to perform relocations with.

Ian> But the usual sense does include a symbol, which is absent in this
Ian> case.

  IMHO, the presense or absense of symbol (or several alternative
symbols to choose from) is conceptually irrelevant.  What matters and
what is essential is the method for obtaining values for external
references.

~velco