<div dir="ltr">That's reasonable, but how would you propose that work?  An analogous fix for ptest-runner is to use ${libdir} instead of /usr/lib (leaving the bbclass intact), but that just flips the problem if you try to run lib32-libfoo-ptest using a 64-bit ptest-runner with default arguments (not specifying -d /usr/lib).  Alternatively, I suppose ptest-runner could look in multiple directories by default (for example, ${libdir} and ${nonarch_libdir}, assuming they're different).  Although, it almost feels like the run-ptest scripts should really be installed to ${libexecdir}.<div><br></div><div>I'll be glad to workup a different patch, but I want to make sure I understand the desired design.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 16, 2018 at 6:12 PM, Burton, Ross <span dir="ltr"><<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On 16 February 2018 at 21:41, Kyle Russell <span dir="ltr"><<a href="mailto:bkylerussell@gmail.com" target="_blank">bkylerussell@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ptest-runner always looks at /usr/lib, so make this arch independent.<br></blockquote><div><br></div></span><div>I'd say the bug here is in ptest-runner.  I'd expect to be able to install libfoo-ptest and lib32-libfoo-ptest in parallel.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Ross </div></font></span></div></div></div>
</blockquote></div><br></div>