Re: Trivial program size inflation

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> No, ld reads the archive in its sequence in the arg list [...] 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).

Even as long ago as 1.4T cc runs ld (well, collect2) with -lgcc -lc
-lgcc, which presumably it wouldn't do without a reason.  (5.2 uses
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh, at least in a simple test I just
did.)

How necessary this is, that's a different question.  Not when linking
null.o into an executable on 5.2; I tried running the ld command with
the second copies of -lgcc -lgcc_eh deleted and it linked just fine.
I've failed to find where the second -lgcc -lgcc_eh is specified,
though (I thought there may be explanatory comments); I searched
/usr/src for -lgcc_eh and found only three hits, none of which appear
to specify the duplication.  I may take a closer look sometime.

Looking at libgcc.a's symbol tables, I see something called _eprintf.o
which refers to stdio things (__sF, abort, fflush, fprintf), and
numerous things refer to abort.  libgcc also provides things like
__fixunssfti which look to me like the backend for compiler-internal
references.  Those might between them explain -lgcc -lc -lgcc.

At least one linker has a way to specify multiple .a libraries which
are, as a set, searched iteratively until they no longer resolve
anything more.  I speculate that the reason cc doesn't use that is that
it wants to be able to work with linkers that don't have any such
mechanism.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B