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

[Christopher Larson]

On Tue, May 3, 2016 at 3:01 AM, Khem Raj <raj.khem at gmail.com> wrote:

>
> On May 2, 2016, at 7:53 PM, Christopher Larson <kergoth at gmail.com> wrote:
>
>
>
> 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.
>
>
> I was taking a application developers point of view. not a system
> integrators or OE build masters. applications are supposed to work on all
> kind of env
> and cross build env is one of them which large app developer community may
> not use as primary environment for development.
>
>
> 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.
>
>
> I thought you were looking for ways to detect if hash styles are mixed or
> not conforming to default for a given architecture. If the end binary is
> getting build as expected
> and we are able to detect if it does not, then it won’t matter if the
> setting came from LDFLAGS or CFLAFS or implicit defaults.
>

No, that's exactly the point. Recipes have clear brokenness, not obeying
LDFLAGS, which is a clear correctness bug, and there's no easy way to
detect that if the toolchain sets the gnu hash style by default.

The only ones spotting these common, clear bugs are those using external
toolchains. The internal toolchain builds are ignoring these bugs by
letting the toolchain set the default regardless of whether it obeys
LDFLAGS or not.
-- 
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/63fd8733/attachment-0002.html>