kumquat-buildroot/package/go/go.mk

166 lines
4.7 KiB
Makefile
Raw Normal View History

################################################################################
#
# go
#
################################################################################
GO_VERSION = 1.19.11
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 \
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)
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
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 $(@D)/pkg/linux_* $(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))