Semantics of a common definition in an archive

[Ian Lance Taylor]

On Tue, Aug 18, 2020 at 10:23 PM Fangrui Song <i@maskray.me> wrote:
>
> .....I have to complain that the Solaris/HP ld treatment on common symbols is too bizarre.
> Hope Ali or Rainer can share with me the rationale.

That's nothing, the SunOS linker was even stranger.  If an object file
had a common definition for C with size S1, and an archive had an
object a.o with a common definition for C with size S2 where S2 > S1,
then a.o would *not* be included in the link (unless it satisfied some
different undefined symbol) but the size of the common symbol would be
increased to S2.  If a linker failed to implement that semantics, the
C library would fail at run time.  GNU ld implements this in
aout_link_check_ar_symbols in bfd/aoutx.h.


> I will make a weak-vs-global analog:
> Suppose both libweak.a and libglobal.a define a symbol which is
> referenced by undef.o.  Let's consider two link orders:
>
> * `undef.o -lweak -lglobal` will pick libweak.a and ignore libglobal.a if
>    libglobal.a does not need fetching. ld does not inspect whether
>    libglobal.a contains a definition which can override libweak.a!
> * `-lglobal undef.o -lweak` does not fetch libglobal.a at all
>
> So to provide a weak definition while allowing an optional strong
> definition, the strong definition needs to be surrounded in --whole-archive.
> More complaints (and an Mach-O example) in https://reviews.llvm.org/D86142#2225447

That sounds right to me.  I'm not sure whether you think this is the
way things should work or not.

When ELF was originally designed, a weak definition of S followed by a
strong definition of S was a multiple-definition error.  A strong
definition of S followed by a weak definition of S was fine, and the
weak definition was ignored.  Unfortunately nobody wrote down that
exact rule, and different linkers implemented it differently.

This also of course affects how we should handle a strong definition
in an archive if we've already seen a weak definition.

Ian