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

[Khem Raj]

> 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 <mailto:raj.khem at gmail.com>> wrote:
> 
>> On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth at gmail.com <mailto:kergoth at gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem at gmail.com <mailto:raj.khem at gmail.com>> wrote:
>> 
>> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth at gmail.com <mailto:kergoth at gmail.com>> wrote:
>> >
>> > From: Christopher Larson <chris_larson at mentor.com <mailto: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.

> --
> 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/20160502/47b9468a/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160502/47b9468a/attachment-0002.sig>