Re: Trivial program size inflation

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 4 Jul 2023 12:03:20 +0000 (UTC)
    From:        RVP <rvp%SDF.ORG@localhost>
    Message-ID:  <e82d4235-0ebd-3419-c786-c28e8dd7eb2d%SDF.ORG@localhost>

  | It should've noticed _all_ the functions in
  | the supplied archive, right?

No, ld reads the archive in its sequence in the arg list,
looks at each included .o file in the order they appear in the .a,
just once, links any objects (.o's) which satisfy currently undefined
references, including any from earlier objects loaded from the .a
(but not later ones) then when it reaches the end of the .a file, it is
done, and nothing will ever return to it again (the .a can be included
on the link command line more than once - about 1 in 10,000,000 cases
[statistic with 0 supporting evidence] that might do something useful).
That's the way it is intended to work, and anything which altered that
would break some usages.

All lorder does is order the .o files in the .a so that objects in it
that reference others (also in it) appear before the ones they reference
(calloc.o would come before malloc.o for example since calloc() calls
malloc() and not vice versa.)   In this case simple lexical order would
work, but that co-incidence is rare.

calloc() wouldn't be linked (as a separate object) into the dummy
application from libbsdmalloc as nothing had referenced it (yet).
It was later referenced by something in libc - but by the time we
get there, libbsdmalloc is done.

This is all quite different from how dynamically linked libraries work
(which, since those are about all anyone cares a lot about any more,
are what the libraries are mostly being built to expect).

kre