"Dave Gotwisner" <Dave.Gotwisner@xxxxxxxxxxxxxxx> writes: > I have a C++ embedded application which has a TON of symbols. Because > of the way the target must be built, our link phase takes about 20 > minutes on a Sun. Several thousand of the symbols are currently global > but can be made local, because they are only used from the one source > file that contains them. When developing and fixing bugs, we may do > compile / link cycles many times in a day. > > From what I understand, all symbols (both local and global) always > appear in the symbol table for the GNU tool chain. (Older compilers I > worked with didn't expose any local symbols outside of the .o). > > Would link times get reduced by making a large % of the symbols that are > currently global into local (ie, static) symbols? Does the linker do a > filtering pass that walks all the objects and libraries in question to > build a list of global symbols that it later works on rather than always > trying to resolve each symbol off the full list? > > Splitting the app into smaller executables isn't possible because of the > architecture and cross dependencies. Linker questions are probably better directed to binutils@xxxxxxxxxxxxxxx See http://sourceware.org/binutils/. The linker does walk through every .o file and gathers all the global symbols into a hash table. It then decides where to place the input sections in the output file. It then walks through every .o file again and computes the relocations and does the final link. When walking through .o files the linker generally ignores the local symbols. The local symbols are only examined if there are any relocations which reference them. It is likely that reducing the number of global symbols will speed up the link. It is unlikely to speed it up very much. I recommend building a profiling version of the linker to see where the time is actually being taken. And make sure you are using the latest version, as the linker normally gets a little bit faster with each new release. Ian
