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