Re: [OE-core] [PATCH] goarch.bbclass: Disable GO_DYNLINK by default
From: Konrad Weihmann <hidden>
Date: 2021-08-21 20:26:25
I'd truly like to oppose the idea of static linking by default, how juicy this idea may sound... But if we switch to static linking, literary no one can be be sure about licensing anymore (to me one of the major weak spots of go). And I'm quite missing some numbers to back the claim that overall image size decreases - for a certain component that might be true, but what about the example of having a lot of go components in the system? Judging from the commit message all I see as an advantage is that one single module (which isn't even served by the core layer) is now building. Could you please provide some numbers for the rest? On 21.08.21 22:09, Oliver Kranz wrote:
quoted hunk ↗ jump to hunk
Static linking has the following benefits: - go-md2man (-> podman) compiles - imagesize reduces, combined linking overhead needs to be > 37643776 (go-runtime) for dynamic linking to be beneficial - reflects the default golang setup User can still enable it, if they needs to. docker-ce, k3s, skopeo are ignoring the flag anyways. Signed-off-by: Oliver Kranz <redacted> --- meta/classes/goarch.bbclass | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass index 92fec16b82..6e9128e44a 100644 --- a/meta/classes/goarch.bbclass +++ b/meta/classes/goarch.bbclass@@ -31,15 +31,7 @@ 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:class-native ?= "" -GO_DYNLINK:class-nativesdk = "" +GO_DYNLINK ?= "" # define here because everybody inherits this class #