Re: [OE-core] Selectable linker (ld or gold) per recipe
On 9/29/2011 7:08 AM, Phil Blundell wrote: On Tue, 2011-09-27 at 18:10 -0700, Khem Raj wrote: I have thought of that and we know about kernel and eglibc but we don't know about rest of apps that we build. I don't know if gold has been deployed distro wide thats why the approach was to have gold replace parts where it really matters then we might have packages where they use linker directly and or have own linker scripts which are tuned to ld and may yield something different with gold of-course those problems should be fixed but having something in place to make package wise choice sounded better to me. I think I would rather wait until such issues actually arise before trying to fix them. Adding per-recipe linker selection seems like quite a lot of mechanism, with associated potential fragility, to solve a problem that might not even exist in reality. Also, thinking about this more, I am not convinced that wrapping ld directly is going to work reliably. If I remember right, gcc inspects some attributes of the target linker (plugin support being the most obvious one) during configure and adapts itself accordingly. plugin support is now supported in both linkers 2.21+ should not be any issue any other differences between both linkers I am not aware that gcc would care when configuring itself Subsequently swapping out the linker under its feet at runtime seems like it would be a bad idea. If it does turn out that there are packages which simply must be built with BFD ld, I think we should either: a) just declare them incompatible with the ld-is-gold DISTRO_FEATURE, and say that the programs in question aren't supported by such DISTROs (which might or might not be a defensible position, depending on the extent to which such programs are a fringe interest); or this could be a starter b) fix the programs and/or gold to make them compatible, or if that's really intractable; or obviously wanted to avoid that c) work with upstream gcc to figurd yes c) build a parallel toolchain which uses BFD ld and has its own copy of gcc which is appropriately configured, and arrange for the recipes in question to find that toolchain in their $PATH. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Selectable linker (ld or gold) per recipe
On Tue, 2011-09-27 at 18:10 -0700, Khem Raj wrote: I have thought of that and we know about kernel and eglibc but we don't know about rest of apps that we build. I don't know if gold has been deployed distro wide thats why the approach was to have gold replace parts where it really matters then we might have packages where they use linker directly and or have own linker scripts which are tuned to ld and may yield something different with gold of-course those problems should be fixed but having something in place to make package wise choice sounded better to me. I think I would rather wait until such issues actually arise before trying to fix them. Adding per-recipe linker selection seems like quite a lot of mechanism, with associated potential fragility, to solve a problem that might not even exist in reality. Also, thinking about this more, I am not convinced that wrapping ld directly is going to work reliably. If I remember right, gcc inspects some attributes of the target linker (plugin support being the most obvious one) during configure and adapts itself accordingly. Subsequently swapping out the linker under its feet at runtime seems like it would be a bad idea. If it does turn out that there are packages which simply must be built with BFD ld, I think we should either: a) just declare them incompatible with the ld-is-gold DISTRO_FEATURE, and say that the programs in question aren't supported by such DISTROs (which might or might not be a defensible position, depending on the extent to which such programs are a fringe interest); or b) fix the programs and/or gold to make them compatible, or if that's really intractable; or c) work with upstream gcc to figurd c) build a parallel toolchain which uses BFD ld and has its own copy of gcc which is appropriately configured, and arrange for the recipes in question to find that toolchain in their $PATH. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Selectable linker (ld or gold) per recipe
Hello 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. We can use two solutions One where target-ld is a wrapper to ld.gold or ld.bfd and calls the linker based on commandline options passed to it e.g arm-oe-linux-gnueabi-ld -gold and arm-oe-linux-gnueabi-ld -bfd and this option can be passed thru the compiler with -Wl and same wrapper gets symlinked to the ld called by compiler driver if no option is specified than bfd linker is used Second option is that we install both linkers and then add necessary option to gcc to select the linker I have not explored this option but it certainly would be useful This can give us some base so we can select linker per recipe Ideas ? Thanks -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Selectable linker (ld or gold) per recipe
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 Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
