[2/7] package/go: expose host CGO linking support

From: "Yann E. MORIN" <yann.morin@orange.com>

Even when configured for cross-compilation, the go compiler is always
able to build natively as well, and this is was we use in Buildroot to
build host go packages. This implies that when the target has
limitations, those limitations thus also apply to the host builds.

This means that, when there is no CGO linking support for the target,
the compiler is built without CGO linking support, and thus CGO linking
is also not available for the host builds.

Of course, when there is no go support for the target, the CGO linking
support only depends on the host architecture.

Add a new Kconfig symbol that repesent whether CGO linking is available
for the host; host packages can then depend on that symbol, like the
target variants do on the corresponding target symbol.

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Perale <thomas.perale@mind.be>
Cc: Christian Stewart <christian@aperture.us>
Cc: Anisse Astier <anisse@astier.eu>
---
 docs/manual/adding-packages-golang.adoc |  3 ++-
 package/go/Config.in.host               | 12 ++++++++++++
 package/go/go.mk                        |  7 ++++---
 3 files changed, 18 insertions(+), 4 deletions(-)

On 01/08/2024 10:45, yann.morin@orange.com wrote:
> From: "Yann E. MORIN" <yann.morin@orange.com>
> 
> Even when configured for cross-compilation, the go compiler is always
> able to build natively as well, and this is was we use in Buildroot to
> build host go packages. This implies that when the target has
> limitations, those limitations thus also apply to the host builds.
> 
> This means that, when there is no CGO linking support for the target,
> the compiler is built without CGO linking support, and thus CGO linking
> is also not available for the host builds.
> 
> Of course, when there is no go support for the target, the CGO linking
> support only depends on the host architecture.
> 
> Add a new Kconfig symbol that repesent whether CGO linking is available
> for the host; host packages can then depend on that symbol, like the
> target variants do on the corresponding target symbol.
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Thomas Perale <thomas.perale@mind.be>
> Cc: Christian Stewart <christian@aperture.us>
> Cc: Anisse Astier <anisse@astier.eu>
> ---
>   docs/manual/adding-packages-golang.adoc |  3 ++-
>   package/go/Config.in.host               | 12 ++++++++++++
>   package/go/go.mk                        |  7 ++++---
>   3 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/manual/adding-packages-golang.adoc b/docs/manual/adding-packages-golang.adoc
> index 3ddbe57afe..aa25426591 100644
> --- a/docs/manual/adding-packages-golang.adoc
> +++ b/docs/manual/adding-packages-golang.adoc
> @@ -49,7 +49,8 @@ infrastructure should depend on +BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS+
>   because Buildroot will automatically add a dependency on +host-go+
>   to such packages.
>   If you need CGO support in your package, you must add a dependency on
> -+BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS+.
> ++BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS+; for host packages,
> +add a dependency on +BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS+.
>   
>   The main macro of the Go package infrastructure is
>   +golang-package+. It is similar to the +generic-package+ macro. The
> diff --git a/package/go/Config.in.host b/package/go/Config.in.host
> index 11ce6df369..eefca03b02 100644
> --- a/package/go/Config.in.host
> +++ b/package/go/Config.in.host
> @@ -36,6 +36,18 @@ config BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS
>   	default y
>   	depends on BR2_PACKAGE_HOST_GO_BOOTSTRAP_STAGE3_ARCH_SUPPORTS
>   
> +# CGO linking for the host. Since we use the same compiler for target
> +# and host, if the target can't do CGO linking, then the host can't.
> +# But if the target is not supported by Go, then the host can do CGO
> +# linking (except when it itself does not support CGO linking).
> +config BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS
> +	bool
> +	default y if BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS
> +	default y if !BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
> +	depends on BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS
> +	depends on BR2_HOSTARCH != "mips64"
> +	depends on BR2_HOSTARCH != "mips64el"
> +
>   # Go packages should select BR2_PACKAGE_HOST_GO
>   config BR2_PACKAGE_HOST_GO
>   	bool
> diff --git a/package/go/go.mk b/package/go/go.mk
> index 660c7a9bad..7e0dfc5880 100644
> --- a/package/go/go.mk
> +++ b/package/go/go.mk
> @@ -91,10 +91,11 @@ else
>   HOST_GO_CGO_ENABLED = 0
>   endif
>   else # !BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
> -# If the target arch does not support go, host-go can still be used to build
> -# packages for the host, and enable cgo. No need to set all the arch stuff
> -#since we will not be cross-compiling.
> +ifeq ($(BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS),y)
>   HOST_GO_CGO_ENABLED = 1
> +else # !BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS
> +HOST_GO_CGO_ENABLED = 0

  There is still a weird situation here: if the host is mips64, then it's 
possible that the host builds do _not_ support CGO, but target builds don't - 
and we still pass CGO_ENABLED=1 for host builds. Of course, host packages that 
rely on CGO should be excluded already in Config.in.host, but what if CGO is 
optional?

  My first intuition was that we should have a separate HOST_GO_HOST_CGO_ENABLED 
for host builds, but the problem still exists for the go-src package itself, 
since it has host and target in a single build. In fact, what will happen when 
you build that package on a mips64 for a target that does support CGO?


  Anyway, I think this patch is still progress, but a bit risky to still apply 
to master just befor the release. So I applied to next instead.

  Regards,
  Arnout


> +endif # BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS
>   endif # BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
>   # Ensure the toolchain is available, whatever the provider
>   HOST_GO_DEPENDENCIES += $(HOST_GO_DEPENDENCIES_CGO)