| Message ID | 20250228155301.1033479-2-jose.quaresma@foundries.io |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC,1/4] go: bump 1.23.0 | expand |
> -----Original Message----- > From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Jose Quaresma via lists.openembedded.org > Sent: den 28 februari 2025 16:53 > To: openembedded-core@lists.openembedded.org > Cc: Jose Quaresma <jose.quaresma@foundries.io> > Subject: [OE-core] [RFC OE-core][PATCH 2/4] goarch: switch the default linking to static > > The dynamic linked standard library /usr/lib/go/pkg/linux_amd64_dynlink/libstd.so > contains reference to TMPDIR that I couldn't fix and this breakes the go-runtime. breakes -> breaks > > The static linking is the default and most used linking in the golang ecosystem. > Even in more restricted environments such as embedded ones the space occupied by > the libstd.so and the golang aplications installed on target is considerably high aplications -> applications > when few golang applications are used, being in the end higher than what it would > be with static linking. > > When we use static linking we can only use the parts of libstd.so that we realy realy -> really > need and thus we do not need to have unused features in the runtime system library. > This way it ends up not even being necessary to install the libstd.so on the target, > which reduces the total space when there are few applications as already mentioned. > > Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> > --- > meta/classes-recipe/goarch.bbclass | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/meta/classes-recipe/goarch.bbclass b/meta/classes- > recipe/goarch.bbclass > index 1ebe03864f..dfe1c64b3b 100644 > --- a/meta/classes-recipe/goarch.bbclass > +++ b/meta/classes-recipe/goarch.bbclass > @@ -38,12 +38,12 @@ BASE_GOARM:armv5 = '5' > # Go supports dynamic linking on a limited set of architectures. > # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go The above comment made more sense when GO_DYNLINK was set to 1 for that limited set of architectures below... > GO_DYNLINK = "" > -GO_DYNLINK:arm ?= "1" > -GO_DYNLINK:aarch64 ?= "1" > -GO_DYNLINK:x86 ?= "1" > -GO_DYNLINK:x86-64 ?= "1" > -GO_DYNLINK:powerpc64 ?= "1" > -GO_DYNLINK:powerpc64le ?= "1" > +GO_DYNLINK:arm ?= "" > +GO_DYNLINK:aarch64 ?= "" > +GO_DYNLINK:x86 ?= "" > +GO_DYNLINK:x86-64 ?= "" > +GO_DYNLINK:powerpc64 ?= "" > +GO_DYNLINK:powerpc64le ?= "" > GO_DYNLINK:class-native ?= "" > GO_DYNLINK:class-nativesdk = "" Any reason to keep the overrides? > > -- > 2.48.1 //Peter
On 2/28/25 7:52 AM, Jose Quaresma via lists.openembedded.org wrote: > The dynamic linked standard library /usr/lib/go/pkg/linux_amd64_dynlink/libstd.so > contains reference to TMPDIR that I couldn't fix and this breakes the go-runtime. > > The static linking is the default and most used linking in the golang ecosystem. > Even in more restricted environments such as embedded ones the space occupied by > the libstd.so and the golang aplications installed on target is considerably high > when few golang applications are used, being in the end higher than what it would > be with static linking. > > When we use static linking we can only use the parts of libstd.so that we realy > need and thus we do not need to have unused features in the runtime system library. > This way it ends up not even being necessary to install the libstd.so on the target, > which reduces the total space when there are few applications as already mentioned. I think it becomes more useful if there are lot of go apps on target, which might not be as common case so perhaps this switch is ok but we need to document it very clearly as defaults have changed users expectations should be aligned as well. > > Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> > --- > meta/classes-recipe/goarch.bbclass | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/meta/classes-recipe/goarch.bbclass b/meta/classes-recipe/goarch.bbclass > index 1ebe03864f..dfe1c64b3b 100644 > --- a/meta/classes-recipe/goarch.bbclass > +++ b/meta/classes-recipe/goarch.bbclass > @@ -38,12 +38,12 @@ BASE_GOARM:armv5 = '5' > # Go supports dynamic linking on a limited set of architectures. > # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go > GO_DYNLINK = "" > -GO_DYNLINK:arm ?= "1" > -GO_DYNLINK:aarch64 ?= "1" > -GO_DYNLINK:x86 ?= "1" > -GO_DYNLINK:x86-64 ?= "1" > -GO_DYNLINK:powerpc64 ?= "1" > -GO_DYNLINK:powerpc64le ?= "1" > +GO_DYNLINK:arm ?= "" > +GO_DYNLINK:aarch64 ?= "" > +GO_DYNLINK:x86 ?= "" > +GO_DYNLINK:x86-64 ?= "" > +GO_DYNLINK:powerpc64 ?= "" > +GO_DYNLINK:powerpc64le ?= "" > GO_DYNLINK:class-native ?= "" > GO_DYNLINK:class-nativesdk = "" > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#212066): https://lists.openembedded.org/g/openembedded-core/message/212066 > Mute This Topic: https://lists.openembedded.org/mt/111436384/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
I am also working to upgrade go to 1.24.0 and fix the buildpath issue, I will send review later //Hongxu
hongxu via lists.openembedded.org <hongxu.jia= eng.windriver.com@lists.openembedded.org> escreveu (sábado, 1/03/2025 à(s) 07:49): > I am also working to upgrade go to 1.24.0 and fix the buildpath issue, I > will send review later > Thanks for working and fixing the buildpath issue. I think this patch still makes some sense and I will probably submit it again but not now. Jose > > //Hongxu > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#212086): > https://lists.openembedded.org/g/openembedded-core/message/212086 > Mute This Topic: https://lists.openembedded.org/mt/111436384/5052612 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > quaresma.jose@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
diff --git a/meta/classes-recipe/goarch.bbclass b/meta/classes-recipe/goarch.bbclass index 1ebe03864f..dfe1c64b3b 100644 --- a/meta/classes-recipe/goarch.bbclass +++ b/meta/classes-recipe/goarch.bbclass @@ -38,12 +38,12 @@ BASE_GOARM:armv5 = '5' # Go supports dynamic linking on a limited set of architectures. # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go GO_DYNLINK = "" -GO_DYNLINK:arm ?= "1" -GO_DYNLINK:aarch64 ?= "1" -GO_DYNLINK:x86 ?= "1" -GO_DYNLINK:x86-64 ?= "1" -GO_DYNLINK:powerpc64 ?= "1" -GO_DYNLINK:powerpc64le ?= "1" +GO_DYNLINK:arm ?= "" +GO_DYNLINK:aarch64 ?= "" +GO_DYNLINK:x86 ?= "" +GO_DYNLINK:x86-64 ?= "" +GO_DYNLINK:powerpc64 ?= "" +GO_DYNLINK:powerpc64le ?= "" GO_DYNLINK:class-native ?= "" GO_DYNLINK:class-nativesdk = ""
The dynamic linked standard library /usr/lib/go/pkg/linux_amd64_dynlink/libstd.so contains reference to TMPDIR that I couldn't fix and this breakes the go-runtime. The static linking is the default and most used linking in the golang ecosystem. Even in more restricted environments such as embedded ones the space occupied by the libstd.so and the golang aplications installed on target is considerably high when few golang applications are used, being in the end higher than what it would be with static linking. When we use static linking we can only use the parts of libstd.so that we realy need and thus we do not need to have unused features in the runtime system library. This way it ends up not even being necessary to install the libstd.so on the target, which reduces the total space when there are few applications as already mentioned. Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> --- meta/classes-recipe/goarch.bbclass | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)