kumquat-buildroot/package/go/go.mk

169 lines
4.7 KiB
Makefile
Raw Normal View History

################################################################################
#
# go
#
################################################################################
GO_VERSION = 1.21.8
GO_SITE = https://storage.googleapis.com/golang
GO_SOURCE = go$(GO_VERSION).src.tar.gz
GO_LICENSE = BSD-3-Clause
GO_LICENSE_FILES = LICENSE
GO_CPE_ID_VENDOR = golang
HOST_GO_DEPENDENCIES = host-go-bootstrap-stage2
pacakge: drop remnants of $(HOST_DIR)/usr It's been ages (5 years at the next release) that we've not installed host packages in $(HOST_DIR)/usr, but we still have a few packages that reference it or install things in there. Drop all of those in one fell swoop. The run-time test still succeeds, and the following defconfig, which should exercise all touched packages [*], does build: BR2_x86_i686=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_NONE=y BR2_SYSTEM_BIN_SH_NONE=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_GAWK=y BR2_PACKAGE_GETTEXT=y BR2_PACKAGE_ABOOTIMG=y BR2_PACKAGE_DBUS_PYTHON=y BR2_PACKAGE_OLA=y BR2_PACKAGE_JIMTCL=y BR2_PACKAGE_LUA=y # BR2_PACKAGE_LUA_32BITS is not set BR2_PACKAGE_ARGPARSE=y BR2_PACKAGE_PERL=y BR2_PACKAGE_PHP=y BR2_PACKAGE_PHP_APCU=y BR2_PACKAGE_PHP_LUA=y BR2_PACKAGE_PHP_PAM=y BR2_PACKAGE_PHP_PECL_DBUS=y BR2_PACKAGE_PYTHON3=y BR2_PACKAGE_PYTHON_CRYPTOGRAPHY=y BR2_PACKAGE_PYTHON_PLY=y BR2_PACKAGE_PYTHON_PYBIND=y BR2_PACKAGE_LIBVA=y BR2_PACKAGE_BIND=y BR2_PACKAGE_BIND_SERVER=y BR2_PACKAGE_BIND_TOOLS=y BR2_PACKAGE_APPARMOR=y BR2_PACKAGE_APPARMOR_BINUTILS=y BR2_PACKAGE_APPARMOR_UTILS=y BR2_PACKAGE_APPARMOR_UTILS_EXTRA=y BR2_PACKAGE_APPARMOR_PROFILES=y BR2_PACKAGE_REFPOLICY=y BR2_PACKAGE_URANDOM_SCRIPTS=y BR2_PACKAGE_BASH=y # embiggen-disk to exercise go BR2_PACKAGE_EMBIGGEN_DISK=y BR2_TARGET_GRUB2=y BR2_TARGET_GRUB2_I386_PC=y BR2_TARGET_GRUB2_I386_EFI=y [*] exceptions: - zfs was not tested: it needs a kernel to be built; - compiler-rt was not tsted: it needs llvm to be built, that takes ages, and other packages already reference the correct location for llvm-config, so it was assumed that is OK. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com> Cc: Anisse Astier <anisse@astier.eu> Cc: Antoine Tenart <atenart@kernel.org> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Asaf Kahlon <asafka7@gmail.com> Cc: Bernd Kuhls <bernd.kuhls@t-online.de> Cc: Christian Stewart <christian@paral.in> Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Cc: Francois Perrad <francois.perrad@gadz.org> Cc: Guillaume William Brs <guillaume.bressaix@gmail.com> Cc: Hervé Codina <herve.codina@bootlin.com> Cc: James Hilliard <james.hilliard1@gmail.com> Cc: José Luis Salvador Rufo <salvador.joseluis@gmail.com> Cc: Julien Boibessot <julien.boibessot@armadeus.com> Cc: Julien Olivain <ju.o@free.fr> Cc: Matt Weber <matthew.weber@collins.com> Cc: Nicolas Carrier <nicolas.carrier@orolia.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Vadim Kochan <vadim4j@gmail.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> --- Changes v1 -> v2: - fix new instance that have crept in (Romain)
2022-07-16 23:04:49 +02:00
HOST_GO_GOPATH = $(HOST_DIR)/share/go-path
HOST_GO_HOST_CACHE = $(HOST_DIR)/share/host-go-cache
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
HOST_GO_ROOT = $(HOST_DIR)/lib/go
pacakge: drop remnants of $(HOST_DIR)/usr It's been ages (5 years at the next release) that we've not installed host packages in $(HOST_DIR)/usr, but we still have a few packages that reference it or install things in there. Drop all of those in one fell swoop. The run-time test still succeeds, and the following defconfig, which should exercise all touched packages [*], does build: BR2_x86_i686=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_NONE=y BR2_SYSTEM_BIN_SH_NONE=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_GAWK=y BR2_PACKAGE_GETTEXT=y BR2_PACKAGE_ABOOTIMG=y BR2_PACKAGE_DBUS_PYTHON=y BR2_PACKAGE_OLA=y BR2_PACKAGE_JIMTCL=y BR2_PACKAGE_LUA=y # BR2_PACKAGE_LUA_32BITS is not set BR2_PACKAGE_ARGPARSE=y BR2_PACKAGE_PERL=y BR2_PACKAGE_PHP=y BR2_PACKAGE_PHP_APCU=y BR2_PACKAGE_PHP_LUA=y BR2_PACKAGE_PHP_PAM=y BR2_PACKAGE_PHP_PECL_DBUS=y BR2_PACKAGE_PYTHON3=y BR2_PACKAGE_PYTHON_CRYPTOGRAPHY=y BR2_PACKAGE_PYTHON_PLY=y BR2_PACKAGE_PYTHON_PYBIND=y BR2_PACKAGE_LIBVA=y BR2_PACKAGE_BIND=y BR2_PACKAGE_BIND_SERVER=y BR2_PACKAGE_BIND_TOOLS=y BR2_PACKAGE_APPARMOR=y BR2_PACKAGE_APPARMOR_BINUTILS=y BR2_PACKAGE_APPARMOR_UTILS=y BR2_PACKAGE_APPARMOR_UTILS_EXTRA=y BR2_PACKAGE_APPARMOR_PROFILES=y BR2_PACKAGE_REFPOLICY=y BR2_PACKAGE_URANDOM_SCRIPTS=y BR2_PACKAGE_BASH=y # embiggen-disk to exercise go BR2_PACKAGE_EMBIGGEN_DISK=y BR2_TARGET_GRUB2=y BR2_TARGET_GRUB2_I386_PC=y BR2_TARGET_GRUB2_I386_EFI=y [*] exceptions: - zfs was not tested: it needs a kernel to be built; - compiler-rt was not tsted: it needs llvm to be built, that takes ages, and other packages already reference the correct location for llvm-config, so it was assumed that is OK. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com> Cc: Anisse Astier <anisse@astier.eu> Cc: Antoine Tenart <atenart@kernel.org> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Asaf Kahlon <asafka7@gmail.com> Cc: Bernd Kuhls <bernd.kuhls@t-online.de> Cc: Christian Stewart <christian@paral.in> Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Cc: Francois Perrad <francois.perrad@gadz.org> Cc: Guillaume William Brs <guillaume.bressaix@gmail.com> Cc: Hervé Codina <herve.codina@bootlin.com> Cc: James Hilliard <james.hilliard1@gmail.com> Cc: José Luis Salvador Rufo <salvador.joseluis@gmail.com> Cc: Julien Boibessot <julien.boibessot@armadeus.com> Cc: Julien Olivain <ju.o@free.fr> Cc: Matt Weber <matthew.weber@collins.com> Cc: Nicolas Carrier <nicolas.carrier@orolia.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Vadim Kochan <vadim4j@gmail.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> --- Changes v1 -> v2: - fix new instance that have crept in (Romain)
2022-07-16 23:04:49 +02:00
HOST_GO_TARGET_CACHE = $(HOST_DIR)/share/go-cache
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
# We pass an empty GOBIN, otherwise "go install: cannot install
# cross-compiled binaries when GOBIN is set"
HOST_GO_COMMON_ENV = \
GO111MODULE=on \
GOFLAGS=-mod=vendor \
GOROOT="$(HOST_GO_ROOT)" \
GOPATH="$(HOST_GO_GOPATH)" \
GOCACHE="$(HOST_GO_TARGET_CACHE)" \
GOMODCACHE="$(HOST_GO_GOPATH)/pkg/mod" \
GOPROXY=off \
GOTOOLCHAIN=local \
PATH=$(BR_PATH) \
GOBIN= \
CGO_ENABLED=$(HOST_GO_CGO_ENABLED)
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
ifeq ($(BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS),y)
ifeq ($(BR2_arm),y)
GO_GOARCH = arm
ifeq ($(BR2_ARM_CPU_ARMV5),y)
GO_GOARM = 5
else ifeq ($(BR2_ARM_CPU_ARMV6),y)
GO_GOARM = 6
else ifeq ($(BR2_ARM_CPU_ARMV7A),y)
GO_GOARM = 7
else ifeq ($(BR2_ARM_CPU_ARMV8A),y)
# Go doesn't support 32-bit GOARM=8 (https://github.com/golang/go/issues/29373)
# but can still benefit from armv7 optimisations
GO_GOARM = 7
endif
else ifeq ($(BR2_aarch64),y)
GO_GOARCH = arm64
else ifeq ($(BR2_i386),y)
GO_GOARCH = 386
# i386: use softfloat if no SSE2: https://golang.org/doc/go1.16#386
ifneq ($(BR2_X86_CPU_HAS_SSE2),y)
GO_GO386 = softfloat
endif
else ifeq ($(BR2_x86_64),y)
GO_GOARCH = amd64
else ifeq ($(BR2_powerpc64),y)
GO_GOARCH = ppc64
else ifeq ($(BR2_powerpc64le),y)
GO_GOARCH = ppc64le
else ifeq ($(BR2_mips64),y)
GO_GOARCH = mips64
else ifeq ($(BR2_mips64el),y)
GO_GOARCH = mips64le
else ifeq ($(BR2_riscv),y)
GO_GOARCH = riscv64
else ifeq ($(BR2_s390x),y)
GO_GOARCH = s390x
endif
# For the convienience of target packages.
HOST_GO_TOOLDIR = $(HOST_GO_ROOT)/pkg/tool/linux_$(GO_GOARCH)
HOST_GO_TARGET_ENV = \
$(HOST_GO_COMMON_ENV) \
GOOS="linux" \
GOARCH=$(GO_GOARCH) \
CC="$(TARGET_CC)" \
CXX="$(TARGET_CXX)" \
CGO_CFLAGS="$(TARGET_CFLAGS)" \
CGO_CXXFLAGS="$(TARGET_CXXFLAGS)" \
CGO_LDFLAGS="$(TARGET_LDFLAGS)" \
GOTOOLDIR="$(HOST_GO_TOOLDIR)"
# The go compiler's cgo support uses threads. If BR2_TOOLCHAIN_HAS_THREADS is
# set, build in cgo support for any go programs that may need it. Note that
# any target package needing cgo support must include
# 'depends on BR2_TOOLCHAIN_HAS_THREADS' in its config file.
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
package/go: cgo for the target needs the toolchain Building go with cgo support needs to build some .c files to generate target support code, and thus calls the cross C compiler, which is failing when the toolchain is not built before host-go: >>> host-go 1.21.1 Building cd .../build/host-go-1.21.1/src && GO111MODULE=off GOCACHE=.../per-package/host-go/host/share/host-go-cache GOROOT_BOOTSTRAP=.../per-package/host-go/host/lib/go-1.19.11 GOROOT_FINAL=.../per-package/host-go/host/lib/go GOROOT=".../build/host-go-1.21.1" GOBIN=".../build/host-go-1.21.1/bin" GOOS=linux CC=/usr/bin/gcc CXX=/usr/bin/g++ CGO_ENABLED=1 CC_FOR_TARGET=".../per-package/host-go/host/bin/arm-linux-gcc" CXX_FOR_TARGET=".../per-package/host-go/host/bin/arm-linux-g++" GOOS="linux" GOARCH=arm GOARM=6 GO_ASSUME_CROSSCOMPILING=1 ./make.bash Building Go cmd/dist using .../per-package/host-go/host/lib/go-1.19.11. (go1.19.11 linux/amd64) go tool dist: cannot invoke C compiler [".../per-package/host-go/host/bin/arm-linux-gcc"]: fork/exec .../per-package/host-go/host/bin/arm-linux-gcc: no such file or directory Go needs a system C compiler for use with cgo. To set a C compiler, set CC=the-compiler. To disable cgo, set CGO_ENABLED=0. This happens systematically with PPD, and happens without PPD when host-go is explicitly built (by running: "make host-go"). Since only CGO support needs to compile C files, only add the toolchain dependency in that case. When the target is not supported by go, then there is obviously no need to depend on the toolchain (even if we unconditionally enable cgo support in only-for-the-host host-go). Signed-off-by: Christian Stewart <christian@aperture.us> [yann.morin@orange.com: - only add the toolchain dependency for target cgo - reword commit log ] Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Anisse Astier <anisse@astier.eu> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-09-25 15:51:08 +02:00
HOST_GO_DEPENDENCIES += toolchain
HOST_GO_CGO_ENABLED = 1
else
HOST_GO_CGO_ENABLED = 0
endif
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
HOST_GO_CROSS_ENV = \
CC_FOR_TARGET="$(TARGET_CC)" \
CXX_FOR_TARGET="$(TARGET_CXX)" \
GOOS="linux" \
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
GOARCH=$(GO_GOARCH) \
$(if $(GO_GO386),GO386=$(GO_GO386)) \
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
$(if $(GO_GOARM),GOARM=$(GO_GOARM)) \
GO_ASSUME_CROSSCOMPILING=1
else # !BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
# host-go can still be used to build packages for the host. No need to set all
# the arch stuff since we will not be cross-compiling.
HOST_GO_CGO_ENABLED = 1
endif # BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
# For the convenience of host golang packages
HOST_GO_HOST_ENV = \
$(HOST_GO_COMMON_ENV) \
GOOS="" \
GOARCH="" \
GOCACHE="$(HOST_GO_HOST_CACHE)" \
CC="$(HOSTCC_NOCCACHE)" \
CXX="$(HOSTCXX_NOCCACHE)" \
CGO_CFLAGS="$(HOST_CFLAGS)" \
CGO_CXXFLAGS="$(HOST_CXXFLAGS)" \
CGO_LDFLAGS="$(HOST_LDFLAGS)"
# The go build system is not compatible with ccache, so use
# HOSTCC_NOCCACHE. See https://github.com/golang/go/issues/11685.
HOST_GO_MAKE_ENV = \
GO111MODULE=off \
GOCACHE=$(HOST_GO_HOST_CACHE) \
GOROOT_BOOTSTRAP=$(HOST_GO_BOOTSTRAP_STAGE2_ROOT) \
GOROOT_FINAL=$(HOST_GO_ROOT) \
GOROOT="$(@D)" \
GOBIN="$(@D)/bin" \
GOOS=linux \
CC=$(HOSTCC_NOCCACHE) \
CXX=$(HOSTCXX_NOCCACHE) \
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
CGO_ENABLED=$(HOST_GO_CGO_ENABLED) \
$(HOST_GO_CROSS_ENV)
define HOST_GO_BUILD_CMDS
cd $(@D)/src && \
package/go: fix building host go toolchain when target isn't supported The go toolchain can cross-compile by default. So most of the time, building a toolchain that supports a target, allows us to also build go binaries for the host. This is how support for host go packages was added: we use the same toolchain that was initially built only for target. But we might want to build a go binary for the host, when compiling a target for which go isn't supported. Then, building host-go will fail: by default, we build go for a specific target, and give the toolchain bootstrap scripts the cross compiler we'll use. This change modifies this behaviour: we only assume the go toolchain is cross-capable if we know the current target is supported. Otherwise this is a simple host go tool. We don't need to set any of the options needed for cross-compilation in that case. Thus, only set all the target-specific go options under a condition that the target arch is supported. The only option we still set is HOST_GO_CGO_ENABLED, and we always set it to enabled. It was also considered to create a separate package to build the go-for-host compiler which would be used for host-go-packages, but that would lead to a lot of duplication and is completely unnecessary. Fixes: http://autobuild.buildroot.net/results/98b9c7aaff2af4d19adfedac00b768d92530ce94 http://autobuild.buildroot.net/results/bed228995ce3778720f991df9b41345a7c724a46 http://autobuild.buildroot.net/results/3b3ea148165b96513ea511ee0d4adb334a6afac8 Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-04-15 22:49:51 +02:00
$(HOST_GO_MAKE_ENV) ./make.bash $(if $(VERBOSE),-v)
endef
define HOST_GO_INSTALL_CMDS
$(INSTALL) -D -m 0755 $(@D)/bin/go $(HOST_GO_ROOT)/bin/go
$(INSTALL) -D -m 0755 $(@D)/bin/gofmt $(HOST_GO_ROOT)/bin/gofmt
mkdir -p $(HOST_DIR)/bin
ln -sf ../lib/go/bin/go $(HOST_DIR)/bin/
ln -sf ../lib/go/bin/gofmt $(HOST_DIR)/bin/
cp -a $(@D)/lib $(HOST_GO_ROOT)/
mkdir -p $(HOST_GO_ROOT)/pkg
cp -a $(@D)/pkg/include $(HOST_GO_ROOT)/pkg/
cp -a $(@D)/pkg/tool $(HOST_GO_ROOT)/pkg/
# The Go sources must be installed to the host/ tree for the Go stdlib.
cp -a $(@D)/src $(HOST_GO_ROOT)/
# Set file timestamps to prevent the Go compiler from rebuilding the stdlib
# when compiling other programs.
find $(HOST_GO_ROOT) -type f -exec touch -r $(@D)/bin/go {} \;
endef
$(eval $(host-generic-package))