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 <bkyleruss...@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.bur...@intel.com> > wrote: > >> On 16 February 2018 at 21:41, Kyle Russell <bkyleruss...@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 >> > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto