<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 11:15 AM, Mark Hatle <span dir="ltr"><<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.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="">On 5/11/16 12:14 PM, Christopher Larson wrote:<br>
> Hmm, interesting. It doesn't actually appear to be using LDFLAGS from the<br>
> environment at all just now. I'll take another look. Thanks.<br>
<br>
</span>CFLAGS and LDFLAGS<span class="aBn" tabindex="0"><span class="aQJ"> should have bee</span></span>n loaded and sanitized by the 'configure'<br>
front end. If this is not happening any longer -- then behavior has changed (or<br>
my understanding of the behavior is wrong.)<br>
<br>
End result, everything specified in CFLAGS and LDFLAGS that is machine neutral<br>
(i.e. not -m32, or -march=i586) should be preserved and used (unless<br>
specifically removed for another reason.)</blockquote></div><br>The configure script doesn't touch either one from the environment. The CFLAGS env var is used as is in the makefiles. Cflags passed in via --cflags= replace the arch cflags, however. Since we don't place anything arch specific in cflags or ldflags, I don't see that this is an issue, and it has a separate argument to handle arch specific cflags.<br>-- <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>