[OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Mon, May 2, 2016 at 9:37 PM, Khem Raj <raj.khem at gmail.com> wrote:

>
> On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth at gmail.com> wrote:
>
>
>
> On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem at gmail.com> wrote:
>
>>
>> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth at gmail.com>
>> wrote:
>> >
>> > From: Christopher Larson <chris_larson at mentor.com>
>> >
>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
>> default to
>> > this in the toolchain, while convenient, actually hides bugs, as a
>> failure to
>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to
>> how we
>> > poison the sysroot -- rather than relying on the default, notice right
>> away if
>> > somoeone isn't obeying the needed flags.
>> >
>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
>> failure,
>> > which is what's often seen with external toolchains. This brings us all
>> on the
>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>> >
>>
>>
>> Default or gnu linkers is to use sysv for legacy reasons and by passing
>> this option
>> to configuring the toolchain we want to make sure that components are
>> using sane defaults
>> even if they have not configured these options.
>>
>
> But that's not what we want. We want to know when we're not passing
> arguments we need to be passing. For example, the sysroot is poisoned
> today, so we *know* when the user is trying to run it without --sysroot=.
>
>
> application makefiles can ignore environment e.g. CC, CXX, LD etc and get
> into same situations.
> as an application writer I may not be interested in using cross
> compilation specific nuances.  We may not
> be able to solve it completely
>


I'm not sure what you mean by that. This is only for gcc-cross and
gcc-cross-canadian. Anyone using those needs to deal with cross issues
regardless.

if you do not pass the right linker flags from compiler driver and also
>> ignore
>> the LDFLAGS then you now have a safe pass for the app to build without
>> GNU hash
>> while I understand it will spread the external toolchain’s pains into
>> internal toolchain
>> I fail to understand the benefit of doing this otherwise.
>
>
> Silently ignoring the fact that recipes ignore LDFLAGS is not good default
> behavior, and this is precisely what oe-core is doing today. If you know of
> a better way to detect that in another QA check, I'm certainly open to
> hearing it.
>
>
> linker would emit .hash for sysv and .gnu.hash section for gnu hash in
> final ELF, may be adding a QA check for that would be enough ?
>

I don't understand what you mean by this. I don't see how you'd be able to
distinguish between a gnu.hash used because of the toolchain defaults and a
gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be
able to detect the lack of the latter without this patch.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160503/b9672b21/attachment-0002.html>