Re: Selectable linker (ld or gold) per recipe

[Khem Raj <raj.khem@gmail.com>]

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