Re: oprofile rebuilds for different MACHINES (sstate)

[Denys Dmytriyenko <denis@denix.org>]

On Tue, Aug 11, 2015 at 09:35:42PM -0700, Khem Raj wrote:
> 
> > On Aug 11, 2015, at 8:26 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> > 
> > So, I've been debugging the issue of oprofile rebuilding from one MACHINE to
> > another (causing PR issues, etc). I was able to trace it down to this line:
> > 
> > EXTRA_OECONF = "--with-kernel=${STAGING_KERNEL_DIR}  --without-x ac_cv_prog_XSLTPROC="
> > 
> > And STAGING_KERNEL_DIR resolves to this:
> > 
> > STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"
> > 
> > Now, obviously, when MACHINE changes, sstate invalidates do_configure and
> > rebuilds oprofile.
> > 
> > The question is, what is the proper fix in this case - mark oprofile as
> > machine-specific with PACKAGE_ARCH = "${MACHINE_ARCH}", since it will be
> > configuring and building against (potentially) completely different kernel
> > tree. So, just mark it explicitly and be safe...
> > 
> > Or another option is to tell sstate to ignore changes to the above variables
> > with this simple line:
> > 
> > EXTRA_OECONF[vardepsexclude] = "STAGING_KERNEL_DIR"
> > 
> > This also does the trick, but I'm a bit worried there could be side-effects of
> > using oprofile against the wrong kernel... Any recommendations?
> 
> Using kernel staging dir is unnecessary here, oprofile’s configure is poking for user space APIs
> in linux/perf_event.h so linux-libc-headers dependency is enough. and use —with-kernel=${STAGING_EXECPREFIXDIR}
> instead of STAGING_KERNEL_DIR, that should fix it.

Thanks. It didn't seem to help with oprofile, as it changes hashes anyway due 
to the kernel:do_populate_sysroot...

But it did help with cryptodev-tests re-packaging - patch is on the list.

-- 
Denys