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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
