On Mon, Jun 14, 2010 at 11:27 AM, David Brown <da...@westcontrol.com> wrote: > On 14/06/2010 11:22, Dave Korn wrote: >> >> On 14/06/2010 05:43, Ian Lance Taylor wrote: >>> >>> David Brown<david.br...@hesbynett.no> writes: >>> >>>> After doing a bit more reading and thinking, it seems to me that >>>> -fwhole-program will be used in most cases where LTO is used. You use >>>> -flto when compiling each source file, then link them with gcc with >>>> -flto and -fwhole-program. Except in the case of libraries or other >>>> files which need external symbols, you will want that combination to >>>> generate optimal code. So if this combination alone, without common >>>> symbols, is going to cause problems, then this would be a much bigger >>>> issue than if it is only triggered by common symbols. >>> >>> That scenario is fine. >>> >>> You can look back to see the problematic case posted earlier. It was >>> a case where one file was compiled with -flto, one file was compiled >>> without -flto, both files defined a common symbol with the same name, >>> the object files were linked together using -flto -fwhole-program, and >>> the gold plugin was not used. All elements are essential to recreate >>> the problem. >> >> Given how many standard libraries export common symbols, I wonder if it >> won't actually happen quite often. "nm /usr/lib/*.a | grep ' C '" gives a >> fair few hits for me. >> > > It seems unlikely that common symbols in a library will be a problem, since > it is very unlikely that the same common symbols will be defined in the > library /and/ in user code, and it is very unlikely that different parts of > the library would be compiled with different -flto settings. > > However, such libraries would give false (hopefully false!) positives in a > warning message triggered by the use of common symbols. Is it possible for > such a warning message to distinguish between common symbols from library > files and common symbols from object files? Would that be too risky?
Commons between shared libraries and a program can't work. Richard.