On Tue, Aug 11, 2015 at 09:35:42PM -0700, Khem Raj wrote: > > > On Aug 11, 2015, at 8:26 PM, Denys Dmytriyenko <de...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core