go-cross: incorrect dependency on tune-specific libgcc

PATCH Patrick Ohly 4 participants 12 messages Apr 10, 2017 – Apr 11, 2017

Share & tools

Patrick Ohly

author

2017-04-10 12:49 UTC #0 lore raw

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):

meta/classes/go.bbclass +1 -1

index 85f71a2e9a6..ac41c80d377 100644
@@ -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}"

meta/recipes-devtools/go/go-cross.inc +1 -1

index 68f5efd6c09..83015b49a99 100644
@@ -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.

Signature · 6 lines

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.

Bruce Ashfield

2017-04-10 12:59 UTC #1 lore raw

Quoted 66 lines · 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):
meta/classes/go.bbclass +0 -0
index 85f71a2e9a6..ac41c80d377 100644
@@ -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}"
meta/classes/go.bbclass +1 -1
-DEPENDS += "go-cross-${TARGET_ARCH}"
+DEPENDS += "go-cross-${TUNE_PKGARCH}"
 DEPENDS_class-native += "go-native"
 
 FILES_${PN}-staticdev += "${GOSRC_FINAL}/${GO_IMPORT}"
meta/recipes-devtools/go/go-cross.inc +0 -0
index 68f5efd6c09..83015b49a99 100644

meta/recipes-devtools/go/go-cross.inc inherit cross · line 6

Quoted 6 lines

meta/recipes-devtools/go/go-cross.inc +1 -1

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

Quoted 22 lines

meta/recipes-devtools/go/go-cross.inc +0 -0
 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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 2 lines

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

Patrick Ohly

author

2017-04-10 13:09 UTC #2 lore raw

Quoted 4 lines · Bruce Ashfield

On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <[email protected]> wrote:

[...]

Quoted 15 lines

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

[...]

Quoted 2 lines

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 ;-}

Signature · 6 lines

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.

Bruce Ashfield

2017-04-10 13:16 UTC #3 lore raw

Quoted 21 lines · Patrick Ohly

Quoted 4 lines · Bruce Ashfield

On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <[email protected]> wrote:

[...]

Quoted 7 lines

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

Quoted 8 lines

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

Quoted 9 lines

[...]
Quoted 2 lines
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

Quoted 14 lines

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.

Signature · 2 lines

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

Patrick Ohly

author

2017-04-10 14:44 UTC #4 lore raw

Quoted 3 lines · Bruce Ashfield

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.

Signature · 6 lines

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.

Patrick Ohly

author

2017-04-11 16:34 UTC #5 lore raw

In reply to Patrick Ohly

Quoted 30 lines · 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.

[...]

Quoted 2 lines

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?

Signature · 6 lines

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.

Khem Raj

2017-04-11 16:40 UTC #6 lore raw

Quoted 44 lines · Patrick Ohly

Quoted 30 lines · 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.
[...]
Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 10 lines

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

Patrick Ohly

author

2017-04-11 16:52 UTC #7 lore raw

Quoted 45 lines · Khem Raj

Quoted 44 lines · Patrick Ohly
Quoted 30 lines · 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.
[...]
Quoted 2 lines
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.

Quoted 7 lines

Quoted 4 lines
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.

Signature · 6 lines

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.

Khem Raj

2017-04-11 17:01 UTC #8 lore raw

Quoted 51 lines · Patrick Ohly

Quoted 50 lines · Khem Raj
Quoted 48 lines · Patrick Ohly
Quoted 30 lines · 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.
[...]
Quoted 2 lines
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?

Quoted 6 lines

Quoted 2 lines
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.

Quoted 14 lines

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.

Patrick Ohly

author

2017-04-11 18:26 UTC #9 lore raw

Quoted 11 lines · Khem Raj

Quoted 7 lines · Patrick Ohly
Quoted 2 lines · Khem Raj
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.

Signature · 6 lines

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.

Richard Purdie

2017-04-11 17:48 UTC #10 lore raw

In reply to Khem Raj

Quoted 79 lines · Khem Raj

On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <[email protected]
Quoted 78 lines
wrote:
Quoted 58 lines · 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.
[...]
Quoted 4 lines
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.

Quoted 8 lines

Quoted 6 lines
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

Khem Raj

2017-04-11 18:22 UTC #11 lore raw

Quoted 89 lines · Richard Purdie

Quoted 79 lines · Khem Raj
On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <[email protected]
Quoted 78 lines
wrote:
Quoted 58 lines · 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.
[...]
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
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.

Quoted 7 lines

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

Quoted 7 lines

Cheers,
Richard