Re: ld can leave undefined symbols in non-relocatable output

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Joshua Oreman wrote:

> I did read all of that, and I'd like to clarify that I'm building a
> statically linked executable, and "normal" undefined symbol references
> (e.g. calling an undefined function) cause errors. It's just this
> special type of reference with an unused .equ that puts an undefined
> symbol entry into the symbol table without causing the link to fail.
> 
> I believe the difference may lie in the fact that the unused .equ does
> not have any relocations that reference the undefined symbol, so there
> is no impediment to proper execution of the code. It seems that the
> static linker decides whether an undefined symbol "matters" based on its
> impact, in terms of relocations that reference it, rather than its
> simple existence. Is this accurate?

  Yes, that's basically it.  As a consequence of there not being any relocs, it
seems that the --no-undefined option doesn't actually complain either - I'm not
sure if that's by design or not, but as you say, a symbol that just sits there
in the symbol table and has no relocs against it is no harm; it just continues
being undefined, so LD has no reason to forbid it in general - even a
statically-linked application might dlopen() something at runtime, after all.

    cheers,
      DaveK