[OE-core] Selectable linker (ld or gold) per recipe

[Khem Raj]

On Tue, Sep 27, 2011 at 12:29 PM, Phil Blundell <philb at gnu.org> wrote:
> 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.
>

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.

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>