Re: [OE-core] oprofile rebuilds for different MACHINES (sstate)

[Denys Dmytriyenko]

On Tue, Aug 11, 2015 at 09:35:42PM -0700, Khem Raj wrote:
> 
> > On Aug 11, 2015, at 8:26 PM, Denys Dmytriyenko  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

Re: [OE-core] oprofile rebuilds for different MACHINES (sstate)

[Philip Balister]

On 08/12/2015 05:26 AM, Denys Dmytriyenko 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:

Why not use perf instead of oprofile?

Philip

 
 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?
 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] oprofile rebuilds for different MACHINES (sstate)

[Khem Raj]

 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.

-Khem


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core