[OE-core] [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 at gmail.com>
Sent: Friday, April 3, 2015 8:28 AM
To: Krishnanjanappa, Jagadeesh
Cc: openembedded-core at 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 at caviumnetworks.com> wrote:
>
> From: "Krishnanjanappa, Jagadeesh" <jagadeesh.krishnanjanappa at 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 at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core