On 2006-08-15, Bruce Stephens <[EMAIL PROTECTED]> wrote: > Well, presumably it's the linker, not GCC as such. So that might be > GNU ld (from binutils?) or some other random linker, depending on what > OS, and the configuration of gcc.
Of course. It's just that linker is very easy to forget, because you never use it directly in practise. > Indeed, I notice that John Levine has a bit of a rant in the classic > "Linkers & Loaders": > > UNIX linkers and many MS Windows linkers take an intermixed list > of object files and libraries on the command line or in a control > file and process each in order, so the programmer can control the > order in which objects are loaded and libraries are searched. > Although in principle this offers a great deal of flexibility > [...], in practice the ordered search provides little extra > utility. [...] > > [...] Because there are rarely any duplicated symbols among the > libraries, if the linker simply searched them all as a group (as > IBM mainframe linkers and AIX linker do) programmers would be well > served. Hmm... There's nothing stopping from supporting that mostly useless control in a linker that simply loaded all symbols in a hash, and only after that resolved them: if the symbol already exists, don't add it there again. More likely this manual ordering is remnant from the times when computers barely had enough memory to run the compiler, let alone to retain in memory the symbols of already processed archives. (With the ordering-restricted approach, one only has to retain in memory the symbols that have not yet been resolved.) But on modern computers -- of the kind on which software is actually compiled -- that's not a big feat, and indeed this restriction does not apply if the object files are directly linked, instead of via a container archive. -- Tuomo
