<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 2, 2016, at 7:53 PM, Christopher Larson <<a href="mailto:kergoth@gmail.com" class="">kergoth@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 2, 2016 at 9:37 PM, Khem Raj <span dir="ltr" class=""><<a href="mailto:raj.khem@gmail.com" target="_blank" class="">raj.khem@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 2, 2016, at 1:37 PM, Christopher Larson <<a href="mailto:kergoth@gmail.com" target="_blank" class="">kergoth@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 2, 2016 at 8:34 PM, Khem Raj <span dir="ltr" class=""><<a href="mailto:raj.khem@gmail.com" target="_blank" class="">raj.khem@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On May 2, 2016, at 1:09 PM, Christopher Larson <<a href="mailto:kergoth@gmail.com" target="_blank" class="">kergoth@gmail.com</a>> wrote:<br class="">
><br class="">
> From: Christopher Larson <<a href="mailto:chris_larson@mentor.com" target="_blank" class="">chris_larson@mentor.com</a>><br class="">
><br class="">
> We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to<br class="">
> this in the toolchain, while convenient, actually hides bugs, as a failure to<br class="">
> obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we<br class="">
> poison the sysroot -- rather than relying on the default, notice right away if<br class="">
> somoeone isn't obeying the needed flags.<br class="">
><br class="">
> This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,<br class="">
> which is what's often seen with external toolchains. This brings us all on the<br class="">
> same page, and makes sure a failure to obey LDFLAGS is seen early.<br class="">
><br class="">
<br class="">
<br class="">
</span>Default or gnu linkers is to use sysv for legacy reasons and by passing this option<br class="">
to configuring the toolchain we want to make sure that components are using sane defaults<br class="">
even if they have not configured these options.<br class=""></blockquote><div class=""><br class=""></div><div class="">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></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">application makefiles can ignore environment e.g. CC, CXX, LD etc and get into same situations.</div><div class="">as an application writer I may not be interested in using cross compilation specific nuances. We may not</div><div class="">be able to solve it completely </div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div><div>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</div><div>and cross build env is one of them which large app developer community may not use as primary environment for development. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><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 class="">
the LDFLAGS then you now have a safe pass for the app to build without GNU hash<br class="">
while I understand it will spread the external toolchain’s pains into internal toolchain<br class="">
I fail to understand the benefit of doing this otherwise.</blockquote></div><br clear="all" class=""><div class="">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></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 ?</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div><div>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</div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">-- <br class=""><div class="gmail_signature"><div dir="ltr" class="">Christopher Larson<br class="">kergoth at gmail dot com<br class="">Founder - BitBake, OpenEmbedded, OpenZaurus<br class="">Maintainer - Tslib<br class="">Senior Software Engineer, Mentor Graphics</div></div>
</div></div>
</div></blockquote></div><br class=""></body></html>