[OE-core] go-cross: incorrect dependency on tune-specific libgcc

[Bruce Ashfield]

On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <patrick.ohly at intel.com>
wrote:

> Hello!
>
> I'm currently extending the yocto-compat-layer.py so that it can detect
> invalid signature changes when changing MACHINE. go-cross-x86_64 shows
> up as broken when comparing signatures for MACHINE=intel-corei7-64 and
> MACHINE=qemux86-64.
>
> Both machines share the same go-cross-x86_64, but that DEPENDS on
> libgcc:
>
> meta/recipes-devtools/go/go.inc:# libgcc is required for the target
> specific libraries to build properly
> meta/recipes-devtools/go/go.inc:DEPENDS += "go-bootstrap-native libgcc"
>
> And libgcc itself depends on the tune flags for the target architecture
> and thus is different for these two machines:
>
> $ bitbake-diffsigs -t go-cross-x86_64 do_prepare_recipe_sysroot -s
> 563f419e3854c2351e2cbbf33a9025f6 64e378fd9853a6cd6a4e7f684f52d2fc
> Hash for dependent task gcc/libgcc_6.3.bb.do_populate_sysroot changed
> from afb6b55c0e2b7d2e816b3d2d214a7326 to 208fac5ae428b07a4aa491b130879e4a
>   Hash for dependent task gcc/libgcc_6.3.bb.do_multilib_install changed
> from 596e1612d7b84b7a9c1b409ee78cca89 to d41e2e835d0abe7646e53e3d63ce00cd
>     Hash for dependent task gcc/libgcc_6.3.bb.do_install changed from
> 9ca4126c69fcceb410253a0603c3d76b to cb0c49687a91ea17f1027c6394baacab
>       Hash for dependent task gcc/libgcc_6.3.bb.do_compile changed from
> ab80902424c73af49257cc3f6fe049aa to 436f978a703476968bd5ae1c1915ee5a
>         Hash for dependent task gcc/libgcc_6.3.bb.do_configure changed
> from eb0c36d87f32ce1ceb7d1e42609578fb to f62c98806faf3a28c2144919b89d3460
>           Hash for dependent task gcc/libgcc_6.3.bb.do_prepare_recipe_sysroot
> changed from b037b950e346bef71a4f8fd2c6a2195c to
> d4564b5730941279392932e3c670a5a5
>             Hash for dependent task gcc/libgcc_6.3.bb.do_fetch changed
> from e64cd9e029ed63ba3a09e5fe085b7057 to ea4d3f9d10544219ceb8591d5a5a4041
>               basehash changed from 8744593af2eddb60244788f2b9476e2d to
> dabeb22478ef501e35311af75119a2cf
>               Variable TUNE_CCARGS value changed:
>               " -m64 [--march=corei7 -mtune=corei7-] {+-march=core2
> -mtune=core2 -msse3+} -mfpmath=sse [--msse4.2-]"
>
> Does this fix look correct? It turns go-cross into a package that is
> specific to the tune flags for the target. That fixes the signature
> check, and go-helloworld for both machines still builds okay (haven't
> tested anything else):
>
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index 85f71a2e9a6..ac41c80d377 100644
> --- a/meta/classes/go.bbclass
> +++ b/meta/classes/go.bbclass
> @@ -26,7 +26,7 @@ export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}"
>  export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}
> ${TARGET_CXXFLAGS}"
>  export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}
> ${TARGET_LDFLAGS}"
>
> -DEPENDS += "go-cross-${TARGET_ARCH}"
> +DEPENDS += "go-cross-${TUNE_PKGARCH}"
>  DEPENDS_class-native += "go-native"
>
>  FILES_${PN}-staticdev += "${GOSRC_FINAL}/${GO_IMPORT}"
> diff --git a/meta/recipes-devtools/go/go-cross.inc
> b/meta/recipes-devtools/go/go-cross.inc
> index 68f5efd6c09..83015b49a99 100644
> --- a/meta/recipes-devtools/go/go-cross.inc
> +++ b/meta/recipes-devtools/go/go-cross.inc
> @@ -2,7 +2,7 @@ inherit cross
>
>  DEPENDS += "gcc-cross-${TARGET_ARCH}"
>
> -PN = "go-cross-${TARGET_ARCH}"
> +PN = "go-cross-${TUNE_PKGARCH}"
>


This requires any layers with existing DEPENDS on go-cross-${TARGET} to be
updated, so
if it is correct .. it would be best to get it in sooner rather than later,
and have some way to
notify when it is actually merged.

Bruce


>
>  FILESEXTRAPATHS =. "${FILE_DIRNAME}/go-cross:"
>
> The alternative would be to drop the libgcc dependency, but I have no
> idea whether that would work at all.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170410/54615f90/attachment-0002.html>