package/crucible: Pass 'osusergo netgo' tags

The 'osusergo netgo' tags need to be passed when CGO_ENABLED=1.

Fixes:

http://autobuild.buildroot.net/results/48a39341ca3dcb3675b2876e680718c3e43f55aa
http://autobuild.buildroot.net/results/897b4803f4f221c52899641a45708b49b7cb5f5c
http://autobuild.buildroot.net/results/3a75c6b73a1f583d6db666eacc45c4debd9218e9

Suggested-by Andrea Barisani <[email protected]>

Signed-off-by Fabio Estevam <[email protected]>

These flags are not crucible specific but they are necessary when compiling static Go binaries with CGO enabled (which crucible does not require by the way) to ensure portability as cgo versions of net and os/users are not portable.

Hello,

On Wed, 20 Jul 2022 17:05:42 +0000
"Barisani, Andrea" <[email protected]> wrote:

Quoted 4 lines

These flags are not crucible specific but they are necessary when compiling static Go binaries with CGO enabled (which crucible does not require by the way) to ensure portability as cgo versions of net and os/users are not portable.

Thanks for your feedback, much appreciated!

So, I see we're passing CGO_ENABLED=1 (when thread support is

available) to all packages, and you're saying that this is incorrect as not all Go packages need CGO? Passing CGO_ENABLED=1/0 should be a per-package decision?

However, when CGO is enabled and we need static linking, passing osusergo and netgo tags is needed, correct?

Thomas

AFAICS, CGO_ENABLED is only set in HOST_GO_MAKE_ENV, which is only used in the
host-go build commands. So it's not really possible to set it per package. However, apparently it is possible to override it:

Hello,

Quoted 3 lines · On Fri, 22 Jul 2022 23:04:57 +0200 Arnout Vandecappelle <[email protected]> wrote:

AFAICS, CGO_ENABLED is only set in HOST_GO_MAKE_ENV, which is only used in the
host-go build commands. So it's not really possible to set it per package. However, apparently it is possible to override it:

I see this:

HOST_GO_COMMON_ENV = \
         GO111MODULE=on \
         GOFLAGS=-mod=vendor \
         GOROOT="$(HOST_GO_ROOT)" \
         GOPATH="$(HOST_GO_GOPATH)" \
         GOPROXY=off \
         PATH=$(BR_PATH) \
         GOBIN= \
         CGO_ENABLED=$(HOST_GO_CGO_ENABLED)

HOST_GO_TARGET_ENV = \
         $(HOST_GO_COMMON_ENV) \
         GOOS="linux" \
         GOARCH=$(GO_GOARCH) \
         GOCACHE="$(HOST_GO_TARGET_CACHE)" \
         CC="$(TARGET_CC)" \
         CXX="$(TARGET_CXX)" \
         CGO_CFLAGS="$(TARGET_CFLAGS)" \
         CGO_CXXFLAGS="$(TARGET_CXXFLAGS)" \
         CGO_LDFLAGS="$(TARGET_LDFLAGS)" \
         GOTOOLDIR="$(HOST_GO_TOOLDIR)"

so HOST_GO_TARGET_ENV has CGO_ENABLED=$(HOST_GO_CGO_ENABLED)

and then HOST_GO_TARGET_ENV gets used in:

# Build package for target
define $(2)_BUILD_CMDS

         $$(foreach d,$$($(2)_BUILD_TARGETS),\
                 cd $$(@D); \
                 $$(HOST_GO_TARGET_ENV) \
                         $$($(2)_GO_ENV) \
                         $$(GO_BIN) build -v $$($(2)_BUILD_OPTS) \
                         -o $$(@D)/bin/$$(or $$($(2)_BIN_NAME),$$(notdir $$(d))) \
                         $$($(2)_GOMOD)/$$(d)
         )

endef

Am I looking wrong?

Thomas

I'd actually expect that the package itself would specify whether it needs cgo
or not. Can we test a build of a package that actually uses cgo to verify if we really need to set it in HOST_GO_COMMON_ENV?

Regardless, we *will* need to set the 'osusergo netgo' tags for all cgo-using
packages when they do use cgo - so either we still need a per-package "enable cgo" option, or we should just always add those tags if cgo is enabled and we're doing static linking.

Is there any reason why this problem is only observed for the crucible package?

Hi all,

Quoted 3 lines · Arnout Vandecappelle

I'd actually expect that the package itself would specify whether it needs cgo
or not. Can we test a build of a package that actually uses cgo to verify if we really need to set it in HOST_GO_COMMON_ENV?

"CGO_ENABLED" informs the compiler that it's OK to use Cgo.

It should still be set to 1 even if the package doesn't use cgo at all.

Quoted 6 lines

Regardless, we *will* need to set the 'osusergo netgo' tags for all cgo-using
packages when they do use cgo - so either we still need a per-package "enable cgo" option, or we should just always add those tags if cgo is enabled and we're doing static linking.

Is there any reason why this problem is only observed for the crucible package?

So, this doesn't work?

FOO_GO_ENV += CGO_ENABLED=0

.. because the package needs tags enabled conditionally if cgo is available or not?

I don't understand why this specific package can't just check HOST_GO_CGO_ENABLED and conditionally add the tags?

These flags are not crucible specific but they are necessary when compiling static Go binaries with CGO enabled (which crucible does not require by the way) to ensure portability as cgo versions of net and os/users are not portable.

Best,
Christian Stewart

Quoted 21 lines · Christian Stewart

Hi all,

Quoted 3 lines · Arnout Vandecappelle

   I'd actually expect that the package itself would specify whether it needs cgo or not. Can we test a build of a package that actually uses cgo to verify if we really need to set it in HOST_GO_COMMON_ENV?

"CGO_ENABLED" informs the compiler that it's OK to use Cgo.

It should still be set to 1 even if the package doesn't use cgo at all.

Quoted 6 lines

   Regardless, we *will* need to set the 'osusergo netgo' tags for all cgo-using packages when they do use cgo - so either we still need a per-package "enable cgo" option, or we should just always add those tags if cgo is enabled and we're doing static linking.

   Is there any reason why this problem is only observed for the crucible package?

So, this doesn't work?

Quoted 7 lines

FOO_GO_ENV += CGO_ENABLED=0

.. because the package needs tags enabled conditionally if cgo is available or not?

I don't understand why this specific package can't just check HOST_GO_CGO_ENABLED and conditionally add the tags?

Quoted 4 lines · Andrea

These flags are not crucible specific but they are necessary when compiling static Go binaries with CGO enabled (which crucible does not require by the way) to ensure portability as cgo versions of net and os/users are not portable.

and we are wondering why only crucible needs those tags, and other Go packages don't. And what is especially weird is the part "which crucible does not require" which makes it sound as if crucible isn't using cgo at all...

It turns out that other packages also do need it, e.g. containerd and delve.

So I moved this to the pkg-golang infra [1], and marked this patch as Superseded.