[PATCH] goarch.bbclass: Disable GO_DYNLINK by default

[PATCH] goarch.bbclass: Disable GO_DYNLINK by default

[Oliver Kranz]

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 <o.kranz.88@gmail.com>
---
 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
 #
-- 
2.32.0

Re: [OE-core] [PATCH] goarch.bbclass: Disable GO_DYNLINK by default

[Konrad Weihmann]

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:
> 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 <o.kranz.88@gmail.com>
> ---
>   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
>   #
> 
> 
> 
> 
> 

Re: [OE-core] [PATCH] goarch.bbclass: Disable GO_DYNLINK by default

[Oliver Kranz]

On 21.08.21 22:26, Konrad Weihmann wrote:
> 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).
> 
I see your point here. The main concern was to get rid of the 37MB go 
std lib but I missed the licensing part. I'll have a deeper look into 
the golang linking.

> 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?
> 
You are right that it depends on the amount of go components and their 
usage of std-lib. Right now, I wasn't able to collect enough components 
to reach the memory overhead of go-runtime. There should be a break-even 
point.

So I can totally see the benefits of dynamic linking by default with an 
opt-out option (which is given by GO_LINKSHARED) to respect the 
licensing part here.

> On 21.08.21 22:09, Oliver Kranz wrote:
>> 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 <o.kranz.88@gmail.com>
>> ---
>>   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
>>   #
>>
>>
>>
>> 
>>

Re: [OE-core] [PATCH] goarch.bbclass: Disable GO_DYNLINK by default

[Robert Berger]

Hi,

On 22/08/2021 01:31, Oliver Kranz wrote:
> On 21.08.21 22:26, Konrad Weihmann wrote:
>> 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).
>>
> I see your point here. The main concern was to get rid of the 37MB go 
> std lib but I missed the licensing part. I'll have a deeper look into 
> the golang linking.

One major issue with licensing and reproducibility is that go pulls in 
dependencies. This issue can also be seen by many other "modern" 
languages and you can also modify your Makefile or Cmake to pull in 
dependencies, but that's not what we typically want when we BitBake.

A workaround for reproducibility is to use a local go cache.

A workaround for licensing is to split the dependencies into separate 
recipes.

Konrad describes it here:

https://bitbakesoda.blogspot.com/2021/04/making-go-not-no-go.html

Now, if we make static linking the default things might get even more 
interesting licensing-wise, depending on whom you ask ;)

I think the main issue here is LGPL2/3 vs. GPL2/3, "derivative work", 
"installation requirements" and what you need to ship for open source 
license compliance.

LGPL2/3:

https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)

https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)

GPL2/3:

https://tldrlegal.com/license/gnu-general-public-license-v2

https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)

derivative work:

The GPL2 license describes it like this: The "Program", below, refers to 
any such program or work, and a "work based on the Program" means either 
the Program or any derivative work under copyright law: that is to say, 
a work containing the Program or a portion of it, either verbatim or 
with modifications and/or translated into another language.

see also:

https://lwn.net/Articles/548216/

"installation requirements":

LGPL3:

If the software is part of a consumer device, you must include the 
installation information necessary to modify and reinstall the software.

GPL3:

If the software is part of a consumer device, you must include the 
installation information necessary to modify and reinstall the software.

Bradley seems to have another opinion lately (July 23, 2021)

https://sfconservancy.org/blog/?author=bkuhn

Regards,

Robert