On Tue, 2011-09-27 at 10:23 -0700, Khem Raj wrote: > We have gold and ld available to us as linker alternatives. When > linking webkit with ld it takes 45 mins and grabs 2G of memory where > as with gold on same machine > it took 7 minutes. But then we can not use gold to link glibc and > kernel and may not work on all supported arches. So gold may not be a > complete replacement for ld. A good solution is that we make it > possible > to choose linker at compile time when building the application. gcc > does not have provisions to select linker on commandline although it > has configure > options to select default linker.
Are there any real-world scenarios where this is actually causing a problem? Glibc already has its own private compiler (i.e. gcc-cross-initial) which it can configure any way it wishes, and the kernel generally likes to call ld directly rather than via the gcc driver. So those two are basically a non-issue as far as gold is concerned. The thing about not working on all arches is also something of an non-problem from this point of view, since if gold doesn't work on a particular architecture (eg mips, I think) then there can't be any question about which linker should be selected and specifying it per-recipe would be pointless. I'm not necessarily opposed to adding a wrapper to make the linker selectable per recipe but it does rather seem to me that it's a solution in search of a problem. And, if it genuinely is a widespread problem I would have rather thought that it ought to be tackled in consultation with gcc upstream, otherwise they might go off and invent a different mechanism for doing the same thing. p. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
