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

[Denys Dmytriyenko <denis@denix.org>]

On Tue, May 03, 2016 at 10:09:13AM +0200, Martin Jansa wrote:
> 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).

I'd like to back Chris and Martin here - using external toolchain as well and 
seeing few GNU_HASH warnings. Some warning are ours (too busy/lazy to fix now) 
but some are upstream recipes, maybe it's time to clean them up collectively?

-- 
Denys


> 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



> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core