On Thu, Dec 2, 2010 at 5:39 PM, Ian Lance Taylor <i...@google.com> wrote: > Cary Coutant <ccout...@google.com> writes: > >>> This isn't quite what should happen, though. If the user does not >>> specify -lm on the link line, then we should not add -lm, even if LTO >>> somehow introduces a function that is defined in libm. Automatically >>> adding -lm would introduce a surprising dynamic dependency in some >>> cases. The user should be explicit about that. >> >> I wouldn't expect the compiler to introduce a call to anything in libm >> when -lm isn't already specified on the command line (that would break >> even without LTO). > > Right--that would break without LTO, but it doesn't follow that we > should make it work with LTO. > >> With what I'm suggesting, we'll only resolve libcalls to libraries >> that were originally specified on the command line. > > OK. Another concern I have with this is that there is no canonical > location across all systems for some of these functions. In general -lc > and -lm will suffice, but on some specific systems they may not. And > there are functions which are in libc on some systems and in libm on > others, such as frexp. So if we have a mapping from function to > library, I'm afraid we may get caught up in system dependencies which > are really kind of irrelevant. What really matters, I think, is not the > specific library per function; it's the set of libraries we need to > rescan. > > >> Another way to do this would be to put a marker in the command line >> that identifies where those libraries begin, and the linker could just >> go back and rescan those libraries if needed, before the final layout >> of the endcaps. > > I like that idea in general, but the difficulty is knowing where to put > the marker. E.g., the user is going to specify -lm, and we are going to > need to rescan it. If the user writes -lm -lmylib1 -lmylib2 we want to > rescan -lm but we don't really need to rescan mylib1 and mylib2. >
All those complexities make 2 stage linking more attractive. I think I can implement it in GNU linker with the current plugin API. Linker just needs to remember the command line options, including --start-group/--end-group -as-needed/--no-as-needed --copy-dt-needed-entries/--no-copy-dt-needed-entries in stage 1. In stage 2, it will place LTO trans files before the first IR file claimed by plugin and process the command line options. --whole-archive may need some special handling. Archives after --whole-archive will be ignored in stage 2. -- H.J.
