[OE-core] [CONSOLIDATED PULL 15/32] conf, recipes: Redefine LINKER_HASH_STYLE

[Khem Raj]

On 8/19/2011 7:26 AM, Richard Purdie wrote:
> On Fri, 2011-08-19 at 10:24 +0100, Phil Blundell wrote:
>> On Thu, 2011-08-18 at 13:55 -0700, Saul Wold wrote:
>>> From: Khem Raj<raj.khem at gmail.com>
>>>
>>> LINKER_HASH_STYLE is not set to either sysv or gnu
>>> depending upon architecture e.g. mips does not support
>>> gnu hash style among the supported architectures so
>>> we make sure its set to 'sysv' form mips
>>>
>>> Linker flags are munged to adhere to renamed variable
>>>
>>> Third option is to set it to 'both' we do
>>> not do that by default but user can still set it
>>
>> It wasn't totally obvious to me why this patch is a good thing.  Can you
>> explain why this change is desirable?

when we build libraries within gcc e.g. libgcc or libstdc++ etc. then
it does not respect injection of LDFLAGS as we do so if we set hash 
style to gnu then it does not get passed to build environment of those
runtime libraries. Now one may argue that its a bug in gcc  but I would 
rather like to use provisions gcc provides.

This patch makes ways for us to specify linker style options to gcc 
configure.
but the bigger problem is that I forgot to attach the gcc patch that 
adds this options to gcc configury:) that however does not impact this
patch so much but the next one where I enable the gcc options.



>>
>> Also, I found the first paragraph of the description above quite hard to
>> understand.  Do you think you could try to reword it to be a bit
>> clearer?

Yes I had a typo in there

  LINKER_HASH_STYLE is not set to either sysv or gnu

should have been

  LINKER_HASH_STYLE is now set to either sysv or gnu
>
> Agreed, I'm also having trouble understanding this change. I guess its
> related to the options passed into gcc but I suspect we can just improve
> the gcc option handling instead.
>
> What I don't like about this patch is forcing a string into LDFLAGS and
> I much prefer the current approach where its either added or its not,
> its not just adding a parameter through the variable.
>

Yes default is sysv so if you do not specify anything then linker 
assumes sysv but since barring mips we pass this option to all 
architecture there should be not much impact on other architectures than 
mips.

> Also, if mips doesn't support this, how is anything at all working at
> the moment?

see last line in distro/include/tcmode-default.inc

TARGET_LINK_HASH_STYLE ?= 
"${@['-Wl,--hash-style=gnu',''][bb.data.getVar('TARGET_ARCH', d, True) 
in ['mips', 'mipsel', 'mips64', 'mips64el']]}"


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