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

[Phil Blundell]

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.