> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
