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

[Khem Raj]

> 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 <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

> 
> 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 ?

> --
> 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/a366ac49/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/a366ac49/attachment-0002.sig>