go-cross: incorrect dependency on tune-specific libgcc

go-cross: incorrect dependency on tune-specific libgcc

[Patrick Ohly]

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}"
 
 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.

Re: go-cross: incorrect dependency on tune-specific libgcc

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4485 bytes --]

On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <patrick.ohly@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@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"

[-- Attachment #2: Type: text/html, Size: 5777 bytes --]

Re: go-cross: incorrect dependency on tune-specific libgcc

[Patrick Ohly]

On Mon, 2017-04-10 at 08:59 -0400, Bruce Ashfield wrote:
> 
> 
> On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <patrick.ohly@intel.com>
> wrote:
[...]
>         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}"
[...]

> This requires any layers with existing DEPENDS on go-cross-${TARGET}
> to be updated,

"inherit go" hides that detail, so only recipes which depend on
go-cross-${TARGET_ARCH} directly instead of using go.bbclass need to be
updated (and perhaps should be changed to use go.bbclass instead?).

But I'm not a go expert, so let's hear from those first ;-}

-- 
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.

Re: go-cross: incorrect dependency on tune-specific libgcc

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

On Mon, Apr 10, 2017 at 9:09 AM, Patrick Ohly <patrick.ohly@intel.com>
wrote:

> On Mon, 2017-04-10 at 08:59 -0400, Bruce Ashfield wrote:
> >
> >
> > On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <patrick.ohly@intel.com>
> > wrote:
> [...]
> >         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}"
> [...]
>
> > This requires any layers with existing DEPENDS on go-cross-${TARGET}
> > to be updated,
>
> "inherit go" hides that detail, so only recipes which depend on
> go-cross-${TARGET_ARCH} directly instead of using go.bbclass need to be
> updated (and perhaps should be changed to use go.bbclass instead?).
>

True!

I don't universally use the go bbclass in oe-core, since my recipes all
predate
it by a significant amount.

Either way, I still have a problem when changes like this merge into
oe-core and
I never know exactly when .. until I get the email of people telling me
that things
are broken in meta-virt :D

Bruce


>
> But I'm not a go expert, so let's hear from those first ;-}
>
> --
> 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.
>
>
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 3378 bytes --]

Re: go-cross: incorrect dependency on tune-specific libgcc

[Patrick Ohly]

On Mon, 2017-04-10 at 09:16 -0400, Bruce Ashfield wrote:

> Either way, I still have a problem when changes like this merge into
> oe-core and I never know exactly when .. until I get the email of
> people telling me that things are broken in meta-virt :D

I'm not sure how to solve this. Now that you mentioned it, I can keep an
eye on it and sent a separate warning once it enters master, but usually
a patch submitter doesn't even get a notification himself that something
was merged.


-- 
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.

Re: go-cross: incorrect dependency on tune-specific libgcc

[Patrick Ohly]

On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly 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. 

[...]

> The alternative would be to drop the libgcc dependency, but I have no
> idea whether that would work at all.

Besides Bruce who pointed out the implications on recipes depending on
go-cross-${TARGET_ARCH}, Richard also had concerns about making go-cross
tune-specific, so I ended up testing the libgcc removal approach. It
happened to build okay, so the patch that I ended up proposing (see
"go-cross: avoid libgcc dependency") just removes libgcc from DEPENDS
for go-cross.

I need to revise the method how its done (i.e. not with DEPENDS_remove),
but besides that, can anyone explain whether such a change might hit
some problems somewhere? Khem?

-- 
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.

Re: go-cross: incorrect dependency on tune-specific libgcc

[Khem Raj]

On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly 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.
>
> [...]
>
>> The alternative would be to drop the libgcc dependency, but I have no
>> idea whether that would work at all.
>
> Besides Bruce who pointed out the implications on recipes depending on
> go-cross-${TARGET_ARCH}, Richard also had concerns about making go-cross
> tune-specific, so I ended up testing the libgcc removal approach. It
> happened to build okay, so the patch that I ended up proposing (see
> "go-cross: avoid libgcc dependency") just removes libgcc from DEPENDS
> for go-cross.
>
> I need to revise the method how its done (i.e. not with DEPENDS_remove),
> but besides that, can anyone explain whether such a change might hit
> some problems somewhere? Khem?
>

I think TUNE_PKGARCH is the granularity it needs for setting GOARM
anyway. It should be fine to change it.

> --
> 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.
>
>
>

Re: go-cross: incorrect dependency on tune-specific libgcc

[Patrick Ohly]

On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly 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.
> >
> > [...]
> >
> >> The alternative would be to drop the libgcc dependency, but I have no
> >> idea whether that would work at all.
> >
> > Besides Bruce who pointed out the implications on recipes depending on
> > go-cross-${TARGET_ARCH}, Richard also had concerns about making go-cross
> > tune-specific, so I ended up testing the libgcc removal approach. It
> > happened to build okay, so the patch that I ended up proposing (see
> > "go-cross: avoid libgcc dependency") just removes libgcc from DEPENDS
> > for go-cross.
> >
> > I need to revise the method how its done (i.e. not with DEPENDS_remove),
> > but besides that, can anyone explain whether such a change might hit
> > some problems somewhere? Khem?
> >
> 
> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
> anyway.

So you are saying the patch that I had proposed initially in this mail
thread (go-cross-${TARGET_ARCH} -> go-cross-${TUNE_PKGARCH}) is the
right solution?

Just want to be absolutely sure, there's not much time to resolve this
for 2.3.

-- 
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.

Re: go-cross: incorrect dependency on tune-specific libgcc

[Richard Purdie]

On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.ohly@intel.com
> > wrote:
> > 
> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly 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.
> > [...]
> > 
> > > 
> > > The alternative would be to drop the libgcc dependency, but I
> > > have no
> > > idea whether that would work at all.
> > Besides Bruce who pointed out the implications on recipes depending
> > on
> > go-cross-${TARGET_ARCH}, Richard also had concerns about making go-
> > cross
> > tune-specific, so I ended up testing the libgcc removal approach.
> > It
> > happened to build okay, so the patch that I ended up proposing (see
> > "go-cross: avoid libgcc dependency") just removes libgcc from
> > DEPENDS
> > for go-cross.
> > 
> > I need to revise the method how its done (i.e. not with
> > DEPENDS_remove),
> > but besides that, can anyone explain whether such a change might
> > hit
> > some problems somewhere? Khem?
> > 
> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
> anyway. It should be fine to change it.

Once we go down the TUNE_PKGARCH route we probably won't get back. I'm
reluctant to give up on this quite so easily since having common tools
make a lot of sense from a build time perspective (and we already have
fun with testing and the time it takes).

We could make arm append a v7 to PN in the v7 case and only have two go
compilers on arm to address the GOARM issue...

Cheers,

Richard

Re: go-cross: incorrect dependency on tune-specific libgcc

[Khem Raj]

On Tue, Apr 11, 2017 at 9:52 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
>> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
>> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly 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.
>> >
>> > [...]
>> >
>> >> The alternative would be to drop the libgcc dependency, but I have no
>> >> idea whether that would work at all.
>> >
>> > Besides Bruce who pointed out the implications on recipes depending on
>> > go-cross-${TARGET_ARCH}, Richard also had concerns about making go-cross
>> > tune-specific, so I ended up testing the libgcc removal approach. It
>> > happened to build okay, so the patch that I ended up proposing (see
>> > "go-cross: avoid libgcc dependency") just removes libgcc from DEPENDS
>> > for go-cross.
>> >
>> > I need to revise the method how its done (i.e. not with DEPENDS_remove),
>> > but besides that, can anyone explain whether such a change might hit
>> > some problems somewhere? Khem?
>> >
>>
>> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
>> anyway.
>
> So you are saying the patch that I had proposed initially in this mail
> thread (go-cross-${TARGET_ARCH} -> go-cross-${TUNE_PKGARCH}) is the
> right solution?

no, dependency on libgcc should be removed from go cross if possible.
Its similar to gcc in that regard.

>
> Just want to be absolutely sure, there's not much time to resolve this
> for 2.3.
>
> --
> 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.
>
>
>

Re: go-cross: incorrect dependency on tune-specific libgcc

[Khem Raj]

On Tue, Apr 11, 2017 at 9:57 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
>> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.ohly@intel.com
>> > wrote:
>> >
>> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly 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.
>> > [...]
>> >
>> > >
>> > > The alternative would be to drop the libgcc dependency, but I
>> > > have no
>> > > idea whether that would work at all.
>> > Besides Bruce who pointed out the implications on recipes depending
>> > on
>> > go-cross-${TARGET_ARCH}, Richard also had concerns about making go-
>> > cross
>> > tune-specific, so I ended up testing the libgcc removal approach.
>> > It
>> > happened to build okay, so the patch that I ended up proposing (see
>> > "go-cross: avoid libgcc dependency") just removes libgcc from
>> > DEPENDS
>> > for go-cross.
>> >
>> > I need to revise the method how its done (i.e. not with
>> > DEPENDS_remove),
>> > but besides that, can anyone explain whether such a change might
>> > hit
>> > some problems somewhere? Khem?
>> >
>> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
>> anyway. It should be fine to change it.
>
> Once we go down the TUNE_PKGARCH route we probably won't get back. I'm
> reluctant to give up on this quite so easily since having common tools
> make a lot of sense from a build time perspective (and we already have
> fun with testing and the time it takes).
>
> We could make arm append a v7 to PN in the v7 case and only have two go
> compilers on arm to address the GOARM issue...

I think thats fine, we can also treat default as v7 and leave v5 as it
is, there may not be anyone using go on v5 on oe

>
> Cheers,
>
> Richard
>
>
>

Re: go-cross: incorrect dependency on tune-specific libgcc

[Patrick Ohly]

On Tue, 2017-04-11 at 10:01 -0700, Khem Raj wrote:
> On Tue, Apr 11, 2017 at 9:52 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
> >> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
> >> anyway.
> >
> > So you are saying the patch that I had proposed initially in this mail
> > thread (go-cross-${TARGET_ARCH} -> go-cross-${TUNE_PKGARCH}) is the
> > right solution?
> 
> no, dependency on libgcc should be removed from go cross if possible.
> Its similar to gcc in that regard.

Good that I asked, because I understood "TUNE_PKGARCH is the granularity
it needs" as the exact opposite ;-}

The "if possible" part is where it gets tricky. There's this comment
next to the DEPENDS saying "libgcc is required for the target specific
libraries to build properly" and I simply have no idea how obviously
it'll break when removing the dependency in go-cross.

Anyway, I'll proceed down that route by rewriting the go.inc. Note that
Richard correctly pointed out that the inclusion of go-1.8.bb in
go-cross-1.8.bb isn't particularly clean, making such a change a bit
more complicated. But I don't want to move content around too much just
for this, so I'll leave the cleanup to the go maintainers.

-- 
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.