Ian Lance Taylor wrote: > In section 3.4 (Linker) I have the same comment: for non-GNU targets, > the native linker is sometimes required, so modifying the linker > should not be a requirement. And the exact handling of .a files is > surprisingly target dependent, so while it would be easy to code an > archive searcher in gcc, it would be tedious, though doable, to get it > right for all platforms. > > Conversely, I don't know much we are going to care about speed here, > but I assume that we are going to care a bit. For the linker to > determine which files to pull in from an archive, it is going to have > to read the symbol tables of all the input objects, and it is going to > have to read the archive symbol table, and it is going to have to read > the symbols table of each object included from an archive. It will > have to build a symbol hash table as it goes along. This isn't fast; > it's a significant component of link time. Since the compiler is also > going to have to build a symbol hash table, it is going to be faster > to have the compiler search the archive symbol table and decide which > objects to pull in. Searching an archive symbol table isn't hard; the > target dependencies come in when deciding which objects to include.
I'm wondering whether we can't simply employ the linker to handle all those issues: Have the driver always (not just as fall-back) call "ld -r" and the linker will pull together all input files, including those from archives, and combine them into one single object file. Then invoke the new "link-optimizer" on that single object file, resulting in an optimized object file. Any reasons why this cannot work? Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
