[yocto] [meta][PATCH] ptest.bbclass: fix path for multilib

Kyle Russell bkylerussell at gmail.com
Wed Mar 14 13:59:15 PDT 2018


I logged a bug for this so not to lose track of it. I'll be glad to do the
work, but I want to make sure it's valuable if something more than a
trivial fix is desired.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12604

On Mon, Feb 19, 2018, 12:46 PM Kyle Russell <bkylerussell at gmail.com> wrote:

> 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}.
>
> I'll be glad to workup a different patch, but I want to make sure I
> understand the desired design.
>
> On Fri, Feb 16, 2018 at 6:12 PM, Burton, Ross <ross.burton at intel.com>
> wrote:
>
>> On 16 February 2018 at 21:41, Kyle Russell <bkylerussell at gmail.com>
>> wrote:
>>
>>> ptest-runner always looks at /usr/lib, so make this arch independent.
>>>
>>
>> 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.
>>
>> Ross
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180314/ceb0d52b/attachment.html>


More information about the yocto mailing list