<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 8:34 PM, Khem Raj <span dir="ltr"><<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On May 2, 2016, at 1:09 PM, Christopher Larson <<a href="mailto:kergoth@gmail.com">kergoth@gmail.com</a>> wrote:<br>
><br>
> From: Christopher Larson <<a href="mailto:chris_larson@mentor.com">chris_larson@mentor.com</a>><br>
><br>
> We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to<br>
> this in the toolchain, while convenient, actually hides bugs, as a failure to<br>
> obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we<br>
> poison the sysroot -- rather than relying on the default, notice right away if<br>
> somoeone isn't obeying the needed flags.<br>
><br>
> This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,<br>
> which is what's often seen with external toolchains. This brings us all on the<br>
> same page, and makes sure a failure to obey LDFLAGS is seen early.<br>
><br>
<br>
<br>
</span>Default or gnu linkers is to use sysv for legacy reasons and by passing this option<br>
to configuring the toolchain we want to make sure that components are using sane defaults<br>
even if they have not configured these options.<br></blockquote><div><br></div><div>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=.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
if you do not pass the right linker flags from compiler driver and also ignore<br>
the LDFLAGS then you now have a safe pass for the app to build without GNU hash<br>
while I understand it will spread the external toolchain’s pains into internal toolchain<br>
I fail to understand the benefit of doing this otherwise.</blockquote></div><br clear="all"><div>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.</div>-- <br><div class="gmail_signature"><div dir="ltr">Christopher Larson<br>kergoth at gmail dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div></div>
</div></div>