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

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]

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

But that doesn't detect if it was set to gnu thanks to respecting
LDFLAGS or thanks to gnu being the default in oe-core built toolchain
(from --with-linker-hash-style) - which means that builds with
external toolchain are still affected if they don't use
--with-linker-hash-style=gnu.

After fixing couple recipes used by our internal builds (which are
using external toolchain) and wondering why nobody else reported
those I agree with Chris, that to detect this early (with current
QA check which already reports when the used hash style doesn't match
with LDFLAGS).

It would be nice to really poison the value if possible
--with-linker-hash-style=YOU_NEED_TO_RESPECT_LDFLAGS
to cause linker call to fail when someone is using oe-core toolchain
outside OE itself (so might ignore LDFLAGS, but without running the
QA check).

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]