[PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

[PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

[Krishnanjanappa, Jagadeesh]

From: "Krishnanjanappa, Jagadeesh" <jagadeesh.krishnanjanappa@caviumnetworks.com>

If a complier supports generating 32-bit and 64-bit binaries, then
while building valgrind we have two sets of binaries (32-bit and 64-bit)
being generated.

Example: With compiler supporting generation of both 32-bit and 64-bit
binaries, and building valgrind in 64-bit mode, we come across following
QA Issue (listing only few of them),

(snip)
ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
-- CUT --

However, we can build only 64-bit or 32-bit binaries in valgrind using
"--enable-only64bit" and "--enable-only32bit" configure options respectively.
And the required configure option can be selected based on SITEINFO_BITS, but
feel that if a compiler supports generation of both type of binaries and it
may be useful for users to have/execute both type of binaries on multilib
environment. So choosing to pack both types of binaries and skip errors if the
architecture type are different using INSANE_SKIP.

Signed-off-by: Krishnanjanappa, Jagadeesh <jagadeesh.krishnanjanappa@caviumnetworks.com>
---
 meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index bf80b16..eaa64c4 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
@@ -32,6 +32,8 @@ SRC_URI[sha256sum] = "fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
 COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
 COMPATIBLE_HOST_armv7a = 'arm.*-linux'
 
+PR = "r1"
+
 inherit autotools ptest
 
 EXTRA_OECONF = "--enable-tls --without-mpicc"
@@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += "${TCLIBC}-dbg"
 
 RDEPENDS_${PN}-ptest += " sed perl glibc-utils perl-module-file-glob"
 
+# skip checking of the Executable and Linkable Format (ELF) type, bit
+# size, and endianness of any binaries. If a compiler supports
+# generating 32-bit, 64-bit binaries, then we have two sets of 
+# binaries i.e 32-bit and 64-bit.
+INSANE_SKIP_${PN} += "arch"
+INSANE_SKIP_${PN}-dbg += "arch"
+
 do_compile_ptest() {
     oe_runmake check
 }
-- 
1.8.2.3

Re: [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

[Khem Raj]

> On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh <Jagadeesh.Krishnanjanappa@caviumnetworks.com> wrote:
> 
> From: "Krishnanjanappa, Jagadeesh" <jagadeesh.krishnanjanappa@caviumnetworks.com>
> 
> If a complier supports generating 32-bit and 64-bit binaries, then
> while building valgrind we have two sets of binaries (32-bit and 64-bit)
> being generated.
> 
> Example: With compiler supporting generation of both 32-bit and 64-bit
> binaries, and building valgrind in 64-bit mode, we come across following
> QA Issue (listing only few of them),
> 
> (snip)
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
> -- CUT --
> 
> However, we can build only 64-bit or 32-bit binaries in valgrind using
> "--enable-only64bit" and "--enable-only32bit" configure options respectively.
> And the required configure option can be selected based on SITEINFO_BITS, but
> feel that if a compiler supports generation of both type of binaries and it
> may be useful for users to have/execute both type of binaries on multilib
> environment. So choosing to pack both types of binaries and skip errors if the
> architecture type are different using INSANE_SKIP.
> 

what is the point of packaging files for which there won’t be any runtime environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA

> Signed-off-by: Krishnanjanappa, Jagadeesh <jagadeesh.krishnanjanappa@caviumnetworks.com>
> ---
> meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +++++++++
> 1 file changed, 9 insertions(+)
> 
> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
> index bf80b16..eaa64c4 100644
> --- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
> +++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
> @@ -32,6 +32,8 @@ SRC_URI[sha256sum] = "fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
> COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
> 
> +PR = "r1"
> +
> inherit autotools ptest
> 
> EXTRA_OECONF = "--enable-tls --without-mpicc"
> @@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += "${TCLIBC}-dbg"
> 
> RDEPENDS_${PN}-ptest += " sed perl glibc-utils perl-module-file-glob"
> 
> +# skip checking of the Executable and Linkable Format (ELF) type, bit
> +# size, and endianness of any binaries. If a compiler supports
> +# generating 32-bit, 64-bit binaries, then we have two sets of 
> +# binaries i.e 32-bit and 64-bit.
> +INSANE_SKIP_${PN} += "arch"
> +INSANE_SKIP_${PN}-dbg += "arch"
> +
> do_compile_ptest() {
>     oe_runmake check
> }
> -- 
> 1.8.2.3
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

[Krishnanjanappa, Jagadeesh]

> what is the point of packaging files for which there won’t be any runtime >environment. You are just better of removing them.
>IMO unless you have multilib environment working
>this patch is just relaxing the QA

With compilers supporting generation of multilib and yocto framework supporting generation of multilib rootfs, one can have this environment often. Instead of removing them, as said we can disable them from generation using configure options. Also the valgrind rpm package do include this files in its package.
Link: http://www.rpmfind.net//linux/RPM/opensuse/13.2/x86_64/valgrind-3.10.0-1.1.x86_64.html

Regards,
Jagadeesh



________________________________________
From: Khem Raj <raj.khem@gmail.com>
Sent: Friday, April 3, 2015 8:28 AM
To: Krishnanjanappa, Jagadeesh
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

> On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh <Jagadeesh.Krishnanjanappa@caviumnetworks.com> wrote:
>
> From: "Krishnanjanappa, Jagadeesh" <jagadeesh.krishnanjanappa@caviumnetworks.com>
>
> If a complier supports generating 32-bit and 64-bit binaries, then
> while building valgrind we have two sets of binaries (32-bit and 64-bit)
> being generated.
>
> Example: With compiler supporting generation of both 32-bit and 64-bit
> binaries, and building valgrind in 64-bit mode, we come across following
> QA Issue (listing only few of them),
>
> (snip)
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
> -- CUT --
>
> However, we can build only 64-bit or 32-bit binaries in valgrind using
> "--enable-only64bit" and "--enable-only32bit" configure options respectively.
> And the required configure option can be selected based on SITEINFO_BITS, but
> feel that if a compiler supports generation of both type of binaries and it
> may be useful for users to have/execute both type of binaries on multilib
> environment. So choosing to pack both types of binaries and skip errors if the
> architecture type are different using INSANE_SKIP.
>

what is the point of packaging files for which there won’t be any runtime environment. You are just better of removing them.
IMO unless you have multilib environment working
this patch is just relaxing the QA


> Signed-off-by: Krishnanjanappa, Jagadeesh <jagadeesh.krishnanjanappa@caviumnetworks.com>
> ---
> meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
> index bf80b16..eaa64c4 100644
> --- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
> +++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
> @@ -32,6 +32,8 @@ SRC_URI[sha256sum] = "fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
> COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>
> +PR = "r1"
> +
> inherit autotools ptest
>
> EXTRA_OECONF = "--enable-tls --without-mpicc"
> @@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += "${TCLIBC}-dbg"
>
> RDEPENDS_${PN}-ptest += " sed perl glibc-utils perl-module-file-glob"
>
> +# skip checking of the Executable and Linkable Format (ELF) type, bit
> +# size, and endianness of any binaries. If a compiler supports
> +# generating 32-bit, 64-bit binaries, then we have two sets of
> +# binaries i.e 32-bit and 64-bit.
> +INSANE_SKIP_${PN} += "arch"
> +INSANE_SKIP_${PN}-dbg += "arch"
> +
> do_compile_ptest() {
>     oe_runmake check
> }
> --
> 1.8.2.3
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

[Mark Hatle]

On 4/3/15 9:57 AM, Krishnanjanappa, Jagadeesh wrote:
>> what is the point of packaging files for which there won’t be any runtime >environment. You are just better of removing them.
>> IMO unless you have multilib environment working
>> this patch is just relaxing the QA
> 
> With compilers supporting generation of multilib and yocto framework supporting generation of multilib rootfs, one can have this environment often. Instead of removing them, as said we can disable them from generation using configure options. Also the valgrind rpm package do include this files in its package.
> Link: http://www.rpmfind.net//linux/RPM/opensuse/13.2/x86_64/valgrind-3.10.0-1.1.x86_64.html

With a multilib configuration, these things should be packaged per-multilib and
then only the installed multilib components are available on the device.  It
saves space and preserves the checking in place to catch situations where you
may accidentally provide software that isn't runnable.

The other problem with permitting the system to query the compiler is the output
of the build is no longer deterministic.  If the toolchain configuration
changes, then the output of valgrind changes.  That should not happen.

--Mark

> Regards,
> Jagadeesh
> 
> 
> 
> ________________________________________
> From: Khem Raj <raj.khem@gmail.com>
> Sent: Friday, April 3, 2015 8:28 AM
> To: Krishnanjanappa, Jagadeesh
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg
> 
>> On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh <Jagadeesh.Krishnanjanappa@caviumnetworks.com> wrote:
>>
>> From: "Krishnanjanappa, Jagadeesh" <jagadeesh.krishnanjanappa@caviumnetworks.com>
>>
>> If a complier supports generating 32-bit and 64-bit binaries, then
>> while building valgrind we have two sets of binaries (32-bit and 64-bit)
>> being generated.
>>
>> Example: With compiler supporting generation of both 32-bit and 64-bit
>> binaries, and building valgrind in 64-bit mode, we come across following
>> QA Issue (listing only few of them),
>>
>> (snip)
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
>> -- CUT --
>>
>> However, we can build only 64-bit or 32-bit binaries in valgrind using
>> "--enable-only64bit" and "--enable-only32bit" configure options respectively.
>> And the required configure option can be selected based on SITEINFO_BITS, but
>> feel that if a compiler supports generation of both type of binaries and it
>> may be useful for users to have/execute both type of binaries on multilib
>> environment. So choosing to pack both types of binaries and skip errors if the
>> architecture type are different using INSANE_SKIP.
>>
> 
> what is the point of packaging files for which there won’t be any runtime environment. You are just better of removing them.
> IMO unless you have multilib environment working
> this patch is just relaxing the QA
> 
> 
>> Signed-off-by: Krishnanjanappa, Jagadeesh <jagadeesh.krishnanjanappa@caviumnetworks.com>
>> ---
>> meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
>> index bf80b16..eaa64c4 100644
>> --- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
>> +++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
>> @@ -32,6 +32,8 @@ SRC_URI[sha256sum] = "fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
>> COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
>> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>
>> +PR = "r1"
>> +
>> inherit autotools ptest
>>
>> EXTRA_OECONF = "--enable-tls --without-mpicc"
>> @@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += "${TCLIBC}-dbg"
>>
>> RDEPENDS_${PN}-ptest += " sed perl glibc-utils perl-module-file-glob"
>>
>> +# skip checking of the Executable and Linkable Format (ELF) type, bit
>> +# size, and endianness of any binaries. If a compiler supports
>> +# generating 32-bit, 64-bit binaries, then we have two sets of
>> +# binaries i.e 32-bit and 64-bit.
>> +INSANE_SKIP_${PN} += "arch"
>> +INSANE_SKIP_${PN}-dbg += "arch"
>> +
>> do_compile_ptest() {
>>     oe_runmake check
>> }
>> --
>> 1.8.2.3
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

[Krishnanjanappa, Jagadeesh]

>With a multilib configuration, these things should be packaged per-multilib and
>then only the installed multilib components are available on the device.  It
>saves space and preserves the checking in place to catch situations where you
>may accidentally provide software that isn't runnable.

>The other problem with permitting the system to query the compiler is the output
>of the build is no longer deterministic.  If the toolchain configuration
>changes, then the output of valgrind changes.  That should not happen.

Ok, got it.
Then disabling the generation of other set of binaries via configure options is 
needed here, i.e install only 32-bit and 64-bit binaries when 32-bit 
and 64-bit valgrind applications are built respectively.

Thanks,
Jagadeesh

________________________________________
From: openembedded-core-bounces@lists.openembedded.org <openembedded-core-bounces@lists.openembedded.org> on behalf of Mark Hatle <mark.hatle@windriver.com>
Sent: Friday, April 3, 2015 8:42 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg

On 4/3/15 9:57 AM, Krishnanjanappa, Jagadeesh wrote:
>> what is the point of packaging files for which there won’t be any runtime >environment. You are just better of removing them.
>> IMO unless you have multilib environment working
>> this patch is just relaxing the QA
>
> With compilers supporting generation of multilib and yocto framework supporting generation of multilib rootfs, one can have this environment often. Instead of removing them, as said we can disable them from generation using configure options. Also the valgrind rpm package do include this files in its package.
> Link: http://www.rpmfind.net//linux/RPM/opensuse/13.2/x86_64/valgrind-3.10.0-1.1.x86_64.html

With a multilib configuration, these things should be packaged per-multilib and
then only the installed multilib components are available on the device.  It
saves space and preserves the checking in place to catch situations where you
may accidentally provide software that isn't runnable.

The other problem with permitting the system to query the compiler is the output
of the build is no longer deterministic.  If the toolchain configuration
changes, then the output of valgrind changes.  That should not happen.

--Mark

> Regards,
> Jagadeesh
>
>
>
> ________________________________________
> From: Khem Raj <raj.khem@gmail.com>
> Sent: Friday, April 3, 2015 8:28 AM
> To: Krishnanjanappa, Jagadeesh
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] valgrind: Add INSANE_SKIP of arch for valgrind and valgrind-dbg
>
>> On Apr 2, 2015, at 11:47 AM, Krishnanjanappa, Jagadeesh <Jagadeesh.Krishnanjanappa@caviumnetworks.com> wrote:
>>
>> From: "Krishnanjanappa, Jagadeesh" <jagadeesh.krishnanjanappa@caviumnetworks.com>
>>
>> If a complier supports generating 32-bit and 64-bit binaries, then
>> while building valgrind we have two sets of binaries (32-bit and 64-bit)
>> being generated.
>>
>> Example: With compiler supporting generation of both 32-bit and 64-bit
>> binaries, and building valgrind in 64-bit mode, we come across following
>> QA Issue (listing only few of them),
>>
>> (snip)
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_exp-sgcheck-x86-linux.so
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/getoff-x86-linux
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_core-x86-linux.so
>> ERROR: QA Issue: Architecture did not match (62 to 3) on ${WORKDIR}/valgrind/3.10.1-r0/packages-split/valgrind-dbg/usr/lib64/valgrind/.debug/vgpreload_memcheck-x86-linux.so
>> -- CUT --
>>
>> However, we can build only 64-bit or 32-bit binaries in valgrind using
>> "--enable-only64bit" and "--enable-only32bit" configure options respectively.
>> And the required configure option can be selected based on SITEINFO_BITS, but
>> feel that if a compiler supports generation of both type of binaries and it
>> may be useful for users to have/execute both type of binaries on multilib
>> environment. So choosing to pack both types of binaries and skip errors if the
>> architecture type are different using INSANE_SKIP.
>>
>
> what is the point of packaging files for which there won’t be any runtime environment. You are just better of removing them.
> IMO unless you have multilib environment working
> this patch is just relaxing the QA
>
>
>> Signed-off-by: Krishnanjanappa, Jagadeesh <jagadeesh.krishnanjanappa@caviumnetworks.com>
>> ---
>> meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
>> index bf80b16..eaa64c4 100644
>> --- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
>> +++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
>> @@ -32,6 +32,8 @@ SRC_URI[sha256sum] = "fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1d
>> COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
>> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>
>> +PR = "r1"
>> +
>> inherit autotools ptest
>>
>> EXTRA_OECONF = "--enable-tls --without-mpicc"
>> @@ -52,6 +54,13 @@ RRECOMMENDS_${PN} += "${TCLIBC}-dbg"
>>
>> RDEPENDS_${PN}-ptest += " sed perl glibc-utils perl-module-file-glob"
>>
>> +# skip checking of the Executable and Linkable Format (ELF) type, bit
>> +# size, and endianness of any binaries. If a compiler supports
>> +# generating 32-bit, 64-bit binaries, then we have two sets of
>> +# binaries i.e 32-bit and 64-bit.
>> +INSANE_SKIP_${PN} += "arch"
>> +INSANE_SKIP_${PN}-dbg += "arch"
>> +
>> do_compile_ptest() {
>>     oe_runmake check
>> }
>> --
>> 1.8.2.3
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core