go: Add recipes for golang compilers and tools
PATCH 1/3 go: Add recipes for golang compilers and tools
This is converging the recipes for go from
meta-virtualization and oe-meta-go
Add recipes for go 1.7
go.bbclass is added to ease out writing
recipes for go packages
--- meta/classes/go.bbclass | 74 +++++++ meta/classes/goarch.bbclass | 46 +++++ meta/recipes-devtools/go/go-1.4.inc | 15 ++ .../go/go-1.4/016-armhf-elf-header.patch | 24 +++ ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +++++++++++++++++++++ meta/recipes-devtools/go/go-1.4/syslog.patch | 62 ++++++ meta/recipes-devtools/go/go-1.6.inc | 19 ++ .../go/go-1.6/armhf-elf-header.patch | 23 +++ .../go/go-1.6/fix-cc-handling.patch | 50 +++++ .../go/go-1.6/fix-target-cc-for-build.patch | 17 ++ meta/recipes-devtools/go/go-1.6/gotooldir.patch | 30 +++ .../go/go-1.6/split-host-and-target-build.patch | 63 ++++++ meta/recipes-devtools/go/go-1.6/syslog.patch | 62 ++++++ meta/recipes-devtools/go/go-1.7.inc | 19 ++ .../go/go-1.7/armhf-elf-header.patch | 23 +++ .../go/go-1.7/fix-cc-handling.patch | 50 +++++ .../go/go-1.7/fix-target-cc-for-build.patch | 17 ++ meta/recipes-devtools/go/go-1.7/gotooldir.patch | 30 +++ .../go/go-1.7/split-host-and-target-build.patch | 62 ++++++ meta/recipes-devtools/go/go-1.7/syslog.patch | 62 ++++++ meta/recipes-devtools/go/go-common.inc | 21 ++ meta/recipes-devtools/go/go-native.inc | 54 +++++ meta/recipes-devtools/go/go-native_1.4.bb | 2 + meta/recipes-devtools/go/go.inc | 76 +++++++ meta/recipes-devtools/go/go_1.6.bb | 4 + meta/recipes-devtools/go/go_1.7.bb | 4 + 26 files changed, 1134 insertions(+) create mode 100644 meta/classes/go.bbclass create mode 100644 meta/classes/goarch.bbclass create mode 100644 meta/recipes-devtools/go/go-1.4.inc create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch create mode 100644 meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch create mode 100644 meta/recipes-devtools/go/go-1.6.inc create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch create mode 100644 meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch create mode 100644 meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch create mode 100644 meta/recipes-devtools/go/go-1.7.inc create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch create mode 100644 meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch create mode 100644 meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch create mode 100644 meta/recipes-devtools/go/go-common.inc create mode 100644 meta/recipes-devtools/go/go-native.inc create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb create mode 100644 meta/recipes-devtools/go/go.inc create mode 100644 meta/recipes-devtools/go/go_1.6.bb create mode 100644 meta/recipes-devtools/go/go_1.7.bb
meta/classes/go.bbclass new file +74 -0
@@ -0,0 +1,74 @@ +inherit goarch + +GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go" +GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go" +GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin" +GOBIN_FINAL = "${GOROOT_FINAL}/bin/${GOOS}_${GOARCH}" + +export GOOS = "${TARGET_GOOS}" +export GOARCH = "${TARGET_GOARCH}" +export GOARM = "${TARGET_GOARM}" +export CGO_ENABLED = "1" +export GOROOT +export GOROOT_FINAL = "${libdir}/${TARGET_SYS}/go" +export GOBIN_FINAL +export GOPKG_FINAL = "${GOROOT_FINAL}/pkg/${GOOS}_${GOARCH}" +export GOSRC_FINAL = "${GOROOT_FINAL}/src" +export GO_GCFLAGS = "${TARGET_CFLAGS}" +export GO_LDFLAGS = "${TARGET_LDFLAGS}" +export CGO_CFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CFLAGS}" +export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}" +export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CXXFLAGS}" +export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_LDFLAGS}" + +DEPENDS += "go-cross" +DEPENDS_class-native += "go-native" + +INHIBIT_PACKAGE_STRIP = "1" + +FILES_${PN}-staticdev += "${GOSRC_FINAL}/${GO_IMPORT}" +FILES_${PN}-staticdev += "${GOPKG_FINAL}/${GO_IMPORT}*" + +GO_INSTALL ?= "${GO_IMPORT}/..." + +do_go_compile() { + GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go env + if test -n "${GO_INSTALL}" ; then + GOPATH=${S}:${STAGING_LIBDIR}/${TARGET_SYS}/go go install -v ${GO_INSTALL} + fi +} + +do_go_install() { + rm -rf ${WORKDIR}/staging + install -d ${WORKDIR}/staging${GOROOT_FINAL} ${D}${GOROOT_FINAL} + tar -C ${S} -cf - . | tar -C ${WORKDIR}/staging${GOROOT_FINAL} -xpvf - + + find ${WORKDIR}/staging${GOROOT_FINAL} \( \ + -name \*.indirectionsymlink -o \ + -name .git\* -o \ + -name .hg -o \ + -name .svn -o \ + -name .pc\* -o \ + -name patches\* \ + \) -print0 | \ + xargs -r0 rm -rf + + tar -C ${WORKDIR}/staging${GOROOT_FINAL} -cf - . | \ + tar -C ${D}${GOROOT_FINAL} -xpvf - + + chown -R root:root "${D}${GOROOT_FINAL}" + + if test -e "${D}${GOBIN_FINAL}" ; then + install -d -m 0755 "${D}${bindir}" + find "${D}${GOBIN_FINAL}" ! -type d -print0 | xargs -r0 mv --target-directory="${D}${bindir}" + rmdir -p "${D}${GOBIN_FINAL}" || true + fi +} + +do_compile() { + do_go_compile +} + +do_install() { + do_go_install +}
meta/classes/goarch.bbclass new file +46 -0
46 lines not on this page · raw message
meta/recipes-devtools/go/go-1.4.inc new file +15 -0
@@ -0,0 +1,15 @@ +require go-common.inc + +PV = "1.4.3" +GO_BASEVERSION = "1.4" +FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:" + +SRC_URI += "\ + file://016-armhf-elf-header.patch \ + file://go-cross-backport-cmd-link-support-new-386-amd64-rel.patch \ + file://syslog.patch \ +" + +LIC_FILES_CHKSUM = "file://LICENSE;md5=591778525c869cdde0ab5a1bf283cd81" +SRC_URI[md5sum] = "dfb604511115dd402a77a553a5923a04" +SRC_URI[sha256sum] = "9947fc705b0b841b5938c48b22dc33e9647ec0752bae66e50278df4f23f64959"
meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch new file +24 -0
@@ -0,0 +1,24 @@ +Description: Use correct ELF header for armhf binaries. +Author: Adam Conrad <[email protected]> +Last-Update: 2013-07-08 + +Upstream-Status: Pending +Signed-off-by: Khem Raj <[email protected]> + +Index: go/src/cmd/ld/elf.c +=================================================================== +--- go.orig/src/cmd/ld/elf.c 2015-02-20 10:49:58.763451586 -0800 ++++ go/src/cmd/ld/elf.c 2015-02-20 10:49:27.895478521 -0800 +@@ -57,7 +57,11 @@ + case '5': + // we use EABI on both linux/arm and freebsd/arm. + if(HEADTYPE == Hlinux || HEADTYPE == Hfreebsd) +- hdr.flags = 0x5000002; // has entry point, Version5 EABI ++#ifdef __ARM_PCS_VFP ++ hdr.flags = 0x5000402; // has entry point, Version5 EABI, hard-float ABI ++#else ++ hdr.flags = 0x5000202; // has entry point, Version5 EABI, soft-float ABI ++#endif + // fallthrough + default: + hdr.phoff = ELF32HDRSIZE; /* Must be be ELF32HDRSIZE: first PHdr must follow ELF header */
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch new file +225 -0
225 lines not on this page · raw message
meta/recipes-devtools/go/go-1.4/syslog.patch new file +62 -0
62 lines not on this page · raw message
meta/recipes-devtools/go/go-1.6.inc new file +19 -0
@@ -0,0 +1,19 @@ +require go-common.inc + +PV = "1.6.3" +GO_BASEVERSION = "1.6" +FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:" + +LIC_FILES_CHKSUM = "file://LICENSE;md5=591778525c869cdde0ab5a1bf283cd81" + +SRC_URI += "\ + file://armhf-elf-header.patch \ + file://syslog.patch \ + file://fix-target-cc-for-build.patch \ + file://fix-cc-handling.patch \ + file://split-host-and-target-build.patch \ + file://gotooldir.patch \ +" +SRC_URI[md5sum] = "bf3fce6ccaadd310159c9e874220e2a2" +SRC_URI[sha256sum] = "6326aeed5f86cf18f16d6dc831405614f855e2d416a91fd3fdc334f772345b00" +
meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch new file +23 -0
@@ -0,0 +1,23 @@ +Encode arm EABI ( hard/soft ) calling convention in ELF header + +Signed-off-by: Khem Raj <[email protected]> +Upstream-Status: Pending +Index: go/src/cmd/link/internal/ld/elf.go +=================================================================== +--- go.orig/src/cmd/link/internal/ld/elf.go ++++ go/src/cmd/link/internal/ld/elf.go +@@ -827,7 +827,13 @@ + // 32-bit architectures + case '5': + // we use EABI on both linux/arm and freebsd/arm. +- if HEADTYPE == obj.Hlinux || HEADTYPE == obj.Hfreebsd { ++ if HEADTYPE == obj.Hlinux { ++ if Ctxt.Goarm == 7 { ++ ehdr.flags = 0x5000402 // has entry point, Version5 EABI, hard float ++ } else { ++ ehdr.flags = 0x5000202 // has entry point, Version5 EABI, soft float ++ } ++ } else if HEADTYPE == obj.Hfreebsd { + // We set a value here that makes no indication of which + // float ABI the object uses, because this is information + // used by the dynamic linker to compare executables and
meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch new file +50 -0
50 lines not on this page · raw message
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch new file +17 -0
@@ -0,0 +1,17 @@ +Put Quotes around CC_FOR_TARGET since it can be mutliple words e.g. in OE + +Signed-off-by: Khem Raj <[email protected]> +Upstream-Status: Pending +Index: go/src/make.bash +=================================================================== +--- go.orig/src/make.bash 2015-07-29 13:28:11.334031696 -0700 ++++ go/src/make.bash 2015-07-29 13:36:55.814465630 -0700 +@@ -158,7 +158,7 @@ + fi + + echo "##### Building packages and commands for $GOOS/$GOARCH." +-CC=$CC_FOR_TARGET "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std cmd ++CC="$CC_FOR_TARGET" "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std cmd + echo + + rm -f "$GOTOOLDIR"/go_bootstrap
meta/recipes-devtools/go/go-1.6/gotooldir.patch new file +30 -0
@@ -0,0 +1,30 @@ +Define tooldir in relation to GOTOOLDIR env var + +Signed-off-by: Khem Raj <[email protected]> +Upstream-Status: Pending +Index: go/src/go/build/build.go +=================================================================== +--- go.orig/src/go/build/build.go ++++ go/src/go/build/build.go +@@ -1388,7 +1388,7 @@ func init() { + } + + // ToolDir is the directory containing build tools. +-var ToolDir = filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH) ++var ToolDir = envOr("GOTOOLDIR", filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH)) + + // IsLocalImport reports whether the import path is + // a local import path, like ".", "..", "./foo", or "../foo". +Index: go/src/cmd/go/build.go +=================================================================== +--- go.orig/src/cmd/go/build.go ++++ go/src/cmd/go/build.go +@@ -1312,7 +1312,7 @@ func (b *builder) build(a *action) (err + } + + cgoExe := tool("cgo") +- if a.cgo != nil && a.cgo.target != "" { ++ if a.cgo != nil && a.cgo.target != "" && os.Getenv("GOTOOLDIR") == "" { + cgoExe = a.cgo.target + } + outGo, outObj, err := b.cgo(a.p, cgoExe, obj, pcCFLAGS, pcLDFLAGS, cgofiles, gccfiles, cxxfiles, a.p.MFiles)
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch new file +63 -0
63 lines not on this page · raw message
meta/recipes-devtools/go/go-1.6/syslog.patch new file +62 -0
62 lines not on this page · raw message
meta/recipes-devtools/go/go-1.7.inc new file +19 -0
@@ -0,0 +1,19 @@ +require go-common.inc + +PV = "1.7.4" +GO_BASEVERSION = "1.7" +FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:" + +LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707" + +SRC_URI += "\ + file://armhf-elf-header.patch \ + file://syslog.patch \ + file://fix-target-cc-for-build.patch \ + file://fix-cc-handling.patch \ + file://split-host-and-target-build.patch \ + file://gotooldir.patch \ +" +SRC_URI[md5sum] = "49c1076428a5d3b5ad7ac65233fcca2f" +SRC_URI[sha256sum] = "4c189111e9ba651a2bb3ee868aa881fab36b2f2da3409e80885ca758a6b614cc" +
meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch new file +23 -0
@@ -0,0 +1,23 @@ +Encode arm EABI ( hard/soft ) calling convention in ELF header + +Signed-off-by: Khem Raj <[email protected]> +Upstream-Status: Pending +Index: go/src/cmd/link/internal/ld/elf.go +=================================================================== +--- go.orig/src/cmd/link/internal/ld/elf.go ++++ go/src/cmd/link/internal/ld/elf.go +@@ -827,7 +827,13 @@ + // 32-bit architectures + case '5': + // we use EABI on both linux/arm and freebsd/arm. +- if HEADTYPE == obj.Hlinux || HEADTYPE == obj.Hfreebsd { ++ if HEADTYPE == obj.Hlinux { ++ if Ctxt.Goarm == 7 { ++ ehdr.flags = 0x5000402 // has entry point, Version5 EABI, hard float ++ } else { ++ ehdr.flags = 0x5000202 // has entry point, Version5 EABI, soft float ++ } ++ } else if HEADTYPE == obj.Hfreebsd { + // We set a value here that makes no indication of which + // float ABI the object uses, because this is information + // used by the dynamic linker to compare executables and
meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch new file +50 -0
50 lines not on this page · raw message
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch new file +17 -0
@@ -0,0 +1,17 @@ +Put Quotes around CC_FOR_TARGET since it can be mutliple words e.g. in OE + +Signed-off-by: Khem Raj <[email protected]> +Upstream-Status: Pending +Index: go/src/make.bash +=================================================================== +--- go.orig/src/make.bash 2015-07-29 13:28:11.334031696 -0700 ++++ go/src/make.bash 2015-07-29 13:36:55.814465630 -0700 +@@ -158,7 +158,7 @@ + fi + + echo "##### Building packages and commands for $GOOS/$GOARCH." +-CC=$CC_FOR_TARGET "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std cmd ++CC="$CC_FOR_TARGET" "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std cmd + echo + + rm -f "$GOTOOLDIR"/go_bootstrap
meta/recipes-devtools/go/go-1.7/gotooldir.patch new file +30 -0
@@ -0,0 +1,30 @@ +Define tooldir in relation to GOTOOLDIR env var + +Signed-off-by: Khem Raj <[email protected]> +Upstream-Status: Pending +Index: go/src/go/build/build.go +=================================================================== +--- go.orig/src/go/build/build.go ++++ go/src/go/build/build.go +@@ -1388,7 +1388,7 @@ func init() { + } + + // ToolDir is the directory containing build tools. +-var ToolDir = filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH) ++var ToolDir = envOr("GOTOOLDIR", filepath.Join(runtime.GOROOT(), "pkg/tool/"+runtime.GOOS+"_"+runtime.GOARCH)) + + // IsLocalImport reports whether the import path is + // a local import path, like ".", "..", "./foo", or "../foo". +Index: go/src/cmd/go/build.go +=================================================================== +--- go.orig/src/cmd/go/build.go ++++ go/src/cmd/go/build.go +@@ -1312,7 +1312,7 @@ func (b *builder) build(a *action) (err + } + + cgoExe := tool("cgo") +- if a.cgo != nil && a.cgo.target != "" { ++ if a.cgo != nil && a.cgo.target != "" && os.Getenv("GOTOOLDIR") == "" { + cgoExe = a.cgo.target + } + outGo, outObj, err := b.cgo(a.p, cgoExe, obj, pcCFLAGS, pcLDFLAGS, cgofiles, gccfiles, cxxfiles, a.p.MFiles)
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch new file +62 -0
62 lines not on this page · raw message
meta/recipes-devtools/go/go-1.7/syslog.patch new file +62 -0
62 lines not on this page · raw message
meta/recipes-devtools/go/go-common.inc new file +21 -0
@@ -0,0 +1,21 @@ +SUMMARY = "Go programming language compiler" +DESCRIPTION = " The Go programming language is an open source project to make \ + programmers more productive. Go is expressive, concise, clean, and\ + efficient. Its concurrency mechanisms make it easy to write programs\ + that get the most out of multicore and networked machines, while its\ + novel type system enables flexible and modular program construction.\ + Go compiles quickly to machine code yet has the convenience of\ + garbage collection and the power of run-time reflection. It's a\ + fast, statically typed, compiled language that feels like a\ + dynamically typed, interpreted language." + +HOMEPAGE = " http://golang.org/" +LICENSE = "BSD-3-Clause" + +inherit goarch + +SRC_URI = "http://golang.org/dl/go${PV}.src.tar.gz" +S = "${WORKDIR}/go" +B = "${S}" + +INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
meta/recipes-devtools/go/go-native.inc new file +54 -0
54 lines not on this page · raw message
meta/recipes-devtools/go/go-native_1.4.bb new file +2 -0
@@ -0,0 +1,2 @@ +require ${PN}.inc +require go-${PV}.inc
meta/recipes-devtools/go/go.inc new file +76 -0
76 lines not on this page · raw message
meta/recipes-devtools/go/go_1.6.bb new file +4 -0
@@ -0,0 +1,4 @@ +require go.inc +require go-${PV}.inc + +BBCLASSEXTEND = "cross"
meta/recipes-devtools/go/go_1.7.bb new file +4 -0
@@ -0,0 +1,4 @@ +require go-${PV}.inc +require go.inc + +BBCLASSEXTEND = "cross"
Signature · 1 line
2.11.1
PATCH 2/3 go-examples: Add an example, helloworld written in go
This should serve as temlate for writing go recipes
--- meta/recipes-extended/go-examples/files/helloworld.go | 10 ++++++++++ meta/recipes-extended/go-examples/go-examples.inc | 10 ++++++++++ meta/recipes-extended/go-examples/go-helloworld_0.1.bb | 15 +++++++++++++++ 3 files changed, 35 insertions(+) create mode 100644 meta/recipes-extended/go-examples/files/helloworld.go create mode 100644 meta/recipes-extended/go-examples/go-examples.inc create mode 100644 meta/recipes-extended/go-examples/go-helloworld_0.1.bb
meta/recipes-extended/go-examples/files/helloworld.go new file +10 -0
@@ -0,0 +1,10 @@ +// You can edit this code! +// Click here and start typing. +// taken from https://golang.org/ +package main + +import "fmt" + +func main() { + fmt.Println("Hello, 世界") +}
meta/recipes-extended/go-examples/go-examples.inc new file +10 -0
@@ -0,0 +1,10 @@ +DESCRIPTION = "This is a simple example recipe that cross-compiles a Go program." +SECTION = "examples" +HOMEPAGE = "https://golang.org/" + +LICENSE = "MIT" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" + +S = "${WORKDIR}" + +inherit go
meta/recipes-extended/go-examples/go-helloworld_0.1.bb new file +15 -0
@@ -0,0 +1,15 @@ +require go-examples.inc + + +SRC_URI += " \ + file://helloworld.go \ +" + +do_compile() { + go build helloworld.go +} + +do_install() { + install -d "${D}/${bindir}" + install -m 0755 "${S}/helloworld" "${D}/${bindir}" +}
Signature · 1 line
2.11.1
PATCH 3/3 go: Fix go cross build with rss
In reply to Khem Rajrecipe specific sysroot demanded changes how cross go compiler was built rename PN to include ARCH_NAME for cross recipe
--- meta/classes/go.bbclass | 2 +- meta/recipes-devtools/go/go-cross.inc | 10 ++++++++++ meta/recipes-devtools/go/go-cross_1.7.bb | 5 +++++ meta/recipes-devtools/go/go_1.7.bb | 2 -- 4 files changed, 16 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-devtools/go/go-cross.inc create mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
meta/classes/go.bbclass +1 -1
@@ -21,7 +21,7 @@ export CGO_CPPFLAGS = "${TARGET_CPPFLAGS}" export CGO_CXXFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_CXXFLAGS}" export CGO_LDFLAGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS} ${TARGET_LDFLAGS}" -DEPENDS += "go-cross" +DEPENDS += "go-cross-${TARGET_ARCH}" DEPENDS_class-native += "go-native" INHIBIT_PACKAGE_STRIP = "1"
meta/recipes-devtools/go/go-cross.inc new file +10 -0
@@ -0,0 +1,10 @@ +inherit cross + +DEPENDS += "gcc-cross-${TARGET_ARCH}" + +PN = "go-cross-${TARGET_ARCH}" + +FILESEXTRAPATHS =. "${FILE_DIRNAME}/go-cross:" + +GOROOT_FINAL ="${libdir}/go" +export GOROOT_FINAL
meta/recipes-devtools/go/go-cross_1.7.bb new file +5 -0
@@ -0,0 +1,5 @@ +require go-cross.inc +require go_${PV}.bb + +# Go binaries are not understood by the strip tool. +INHIBIT_SYSROOT_STRIP = "1"
meta/recipes-devtools/go/go_1.7.bb +0 -2
@@ -1,4 +1,2 @@ require go-${PV}.inc require go.inc - -BBCLASSEXTEND = "cross"
Signature · 1 line
2.11.1
Quoted 3 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-go
I'm still of the opinion that this should be in meta-go, not oe-core...
(but totally agree that converging is essential)
Ross
Quoted 9 lines · Ross
Quoted 3 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe-core...
I think we have to make multiple layers agree on using one layer I find atleast 3 which carry go recipes along with, if its in OE-Core either these layers become redundant or layers which are housing go recipes for
different purpose like meta-virtualization can then drop the compiler recipes it will be easier from consolidation point of view.
if we dont want to take it into OE-Core, we should create a new layer meta-golang on yp git and then help request community to converge to it, it still can be ignored by layers.
Quoted 3 lines
(but totally agree that converging is essential)
Ross
Quoted 14 lines · NZDT Khem Raj
Quoted 5 lines · Ross
Quoted 2 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe-core...
I think we have to make multiple layers agree on using one layer I find atleast 3 which carry go recipes along with, if its in OE-Core either these layers become redundant or layers which are housing go recipes for
different purpose like meta-virtualization can then drop the compiler recipes it will be easier from consolidation point of view.
Quoted 3 lines
if we dont want to take it into OE-Core, we should create a new layer meta-golang on yp git and then help request community to converge to it, it still can be ignored by layers.
Have we tried asking all of the various people involved if they'd mind working together? If not, I have my doubts as to whether putting it in OE-Core is going to entirely resolve the situation.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 2 lines · EST Paul Eggleton
Quoted 1 line · NZDT Khem Raj
On Tue, Feb 7, 2017 at 9:35 AM, Burton, Ross <[email protected]>
Quoted 13 lines · wrote:
Quoted 13 lines
Quoted 5 lines · Khem Raj
Quoted 2 lines
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe-core...
I think we have to make multiple layers agree on using one layer I find atleast 3 which carry go recipes along with, if its in OE-Core either these layers become redundant or layers which are housing go recipes for
different purpose like meta-virtualization can then drop the compiler recipes it will be easier from consolidation point of view.
Quoted 7 lines
Quoted 3 lines
if we dont want to take it into OE-Core, we should create a new layer meta-golang on yp git and then help request community to converge to it, it still can be ignored by layers.
Have we tried asking all of the various people involved if they'd mind working together? If not, I have my doubts as to whether putting it in OE-Core is going to entirely resolve the situation.
I have done a bunch of the work for go support in meta-virtualization. I am currently doing some updates around issues which per recipe sysroots uncovered. I think we would be fine moving our support out of meta-virt if support was somewhere where our changes would be taken/considered and merges would be done in a timely manner, something that hasn't always been the case with the previous attempts to centralize go.
Feel free to ping me on this, I will try to find time to try it out and will work to get it to the point where we can consider removing parts/all from meta-virt.
MarkA
Quoted 3 lines
Cheers,
Paul
Quoted 15 lines · Paul Eggleton
Quoted 14 lines · NZDT Khem Raj
Quoted 5 lines · Ross
Quoted 2 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe-core...
I think we have to make multiple layers agree on using one layer I find atleast 3 which carry go recipes along with, if its in OE-Core either these layers become redundant or layers which are housing go recipes for
different purpose like meta-virtualization can then drop the compiler recipes it will be easier from consolidation point of view.
Quoted 7 lines
Quoted 3 lines
if we dont want to take it into OE-Core, we should create a new layer meta-golang on yp git and then help request community to converge to it, it still can be ignored by layers.
Have we tried asking all of the various people involved if they'd mind working together? If not, I have my doubts as to whether putting it in OE-Core is going to entirely resolve the situation.
As the meta-golang maintainer, I'd be happy to help with converging, whether it's a separate layer or pulled into OE-Core.
-Matt
Quoted 13 lines
Cheers,
Paul--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 8 lines · Ross
Quoted 4 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-go
I'm still of the opinion that this should be in meta-go, not oe- core...
FWIW I disagree. Go is a popular systems language and we're increasingly supporting a wide-array of systems with OE (from iot to ivi and beyond).
Go is already in wide enough use and duplicated in enough layers that we would be doing folks a favour by including it in OE-Core and our build/test cycle.
Joshua
Quoted 7 lines · Joshua Lock
Quoted 6 lines · Ross
Quoted 3 lines · On 7 February 2017 at 04:24, Khem Raj <[email protected]…
This is converging the recipes for go from
meta-virtualization and oe-meta-go
Quoted 7 lines
Quoted 1 line
I'm still of the opinion that this should be in meta-go, not oe-core...
FWIW I disagree. Go is a popular systems language and we're increasingly supporting a wide-array of systems with OE (from iot to ivi and beyond).
Go is already in wide enough use and duplicated in enough layers that we would be doing folks a favour by including it in OE-Core and our build/test cycle.
I agree - if ruby is OE-core worthy, go most certainly is.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 3 lines · Gary Thomas
I agree - if ruby is OE-core worthy, go most certainly is.
webkit-gtk needs ruby-native as a build dependency. If that wasn't the case ruby would almost certainly not be in oe-core.
Jussi
Quoted 8 lines · Jussi Kukkonen
Quoted 3 lines · Gary Thomas
I agree - if ruby is OE-core worthy, go most certainly is.
webkit-gtk needs ruby-native as a build dependency. If that wasn't the case ruby would almost certainly not be in oe-core.
This: ruby was added from meta-ruby because we really wanted webkit and ruby is a build dependency. If webkit wasn't in oe-core then the ruby runtime would likely still be in meta-ruby, where it was a great example of a language layer.
Ross
Quoted 9 lines · Gary Thomas
Quoted 7 lines
FWIW I disagree. Go is a popular systems language and we're increasingly supporting a wide-array of systems with OE (from iot to ivi and beyond).
Go is already in wide enough use and duplicated in enough layers that we would be doing folks a favour by including it
in OE-Core and our build/test cycle.I agree - if ruby is OE-core worthy, go most certainly is.
Ruby is in oe-core only because it's needed by webkit.
As an oe-core maintainer, I think the bar for adding stuff to oe-core should be higher than "it's popular" or "various existing layers are causing duplication of effort and aren't cooperating". The more things we have to support, the less time there is to do a good job with any specific item.
Alex
Quoted 12 lines · Joshua Lock
On Tue, 2017-02-07 at 17:35 +0000, Burton, Ross wrote:
On 7 February 2017 at 04:24, Khem Raj <[email protected]> wrote:
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe-core...
Quoted 7 lines
FWIW I disagree. Go is a popular systems language and we're increasingly supporting a wide-array of systems with OE (from iot to ivi and beyond).
Go is already in wide enough use and duplicated in enough layers that we would be doing folks a favour by including it in OE-Core and our build/test cycle.
I said as much during the oe developer meeting in Berlin last year as well.
I've done work in meta-virt out of necessity, as the cadence of the various layers
was easily getting out of sync. The problem with 'language layers', is that they
update based on the tools/packages/libs and not a system level use case.
Having something in oe-core forces that cadence of updates + QA that makes it much easier to use as part of the eco system.
My Canadian 2 cents worth,
Bruce
Quoted 10 lines
Joshua
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 9 lines · Ross
Quoted 3 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe- core...
(but totally agree that converging is essential)
I've just been reading the various responses.
The benefit of core would be that it would get included in some of the core test builds/coverage and that we've have the maintainer structure that core has to help ensure patches get merged, if that has been a problem in the past.
The downside is more pressure onto the OE-Core maintainers in various ways.
I would like to see the duplication removed and have one good solution for it. If adding it to core is how we achieve that, great, I can work with that (and we can always split it out again) but I'm open to other ideas too, if they can work...
Cheers,
Richard
Quoted 18 lines · Richard Purdie
Quoted 9 lines · Ross
Quoted 3 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe- core...
(but totally agree that converging is essential)
I've just been reading the various responses.
The benefit of core would be that it would get included in some of the core test builds/coverage and that we've have the maintainer structure that core has to help ensure patches get merged, if that has been a problem in the past.
Quoted 7 lines
The downside is more pressure onto the OE-Core maintainers in various ways.
I would like to see the duplication removed and have one good solution for it. If adding it to core is how we achieve that, great, I can work with that (and we can always split it out again) but I'm open to other ideas too, if they can work...
There are more layers which are using go for application development e.g. meta-mender etc. I think ecosystem will benefit if it was in OE-Core and second best solution would be to start a layer e.g. meta-go on yp.org. I am fine with either approach in that order.
Quoted 28 lines · Khem Raj
Quoted 18 lines · Richard Purdie
Quoted 9 lines · Ross
Quoted 3 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goI'm still of the opinion that this should be in meta-go, not oe- core...
(but totally agree that converging is essential)
I've just been reading the various responses.
The benefit of core would be that it would get included in some of the core test builds/coverage and that we've have the maintainer structure that core has to help ensure patches get merged, if that has been a problem in the past.
Quoted 7 lines
The downside is more pressure onto the OE-Core maintainers in various ways.
I would like to see the duplication removed and have one good solution for it. If adding it to core is how we achieve that, great, I can work with that (and we can always split it out again) but I'm open to other ideas too, if they can work...
Quoted 4 lines
There are more layers which are using go for application development e.g. meta-mender etc. I think ecosystem will benefit if it was in OE-Core and second best solution would be to start a layer e.g. meta-go on yp.org. I am fine with either approach in that order.
Alternatively, I think that OE maintainers would not mind carrying meta-go in their meta-openembedded. There's already a couple of important languages there (eg. Lua, albeit in meta-oe) and a number of language specific layers (meta-python, meta-ruby, meta-perl). There's additional benefit of being included in 'bitbake world' jobs.
Signature · 2 lines
Maciej Borzecki RnDity
Quoted 7 lines · Khem Raj
This is converging the recipes for go from
meta-virtualization and oe-meta-goAdd recipes for go 1.7
go.bbclass is added to ease out writing
recipes for go packages
I took these for a spin with current mender tree. Mender is somewhat interesting as we build binaries for the target (Mender client) and some extra tools for the host (mender-artifact tool). I was able to build the client code successfully. I ran into some problems with mender-artifact-native.
The native build problem stems from the fact that there's a single go-native recipe, currently supporting only Go 1.4. Ideally mender-artifact code could be built under Go 1.7 and newer with no problem, 1.4 not so much. We already set PREFERRED_VERSION for both go and go-native to 1.7% so bitbake proceeds with the build and logs:
NOTE: preferred version 1.7 of go-native not available (for item go-native)
NOTE: versions of go-native available: 1.4.3
However, in order to build a native Go 1.7 toolchain we would still need to build Go 1.4. The limitation comes directly from the way Go is built. You to have the so called 'bootstrap' Go (v1.4.2) in order to build Go >= 1.5. Thus we end up in a situation where both go-native_1.4 and go-native_1.7 would need to be built.
I don't know how make both go-native recipes build and depend on another. Maybe someone with more Bitbake kung-fu can step in and propose a method. In oe-meta-go this is fixed in somewhat trivial manner. Namely, there's a go-bootstrap recipe
https://github.com/mem/oe-meta-go/tree/master/recipes-devtools/go With this all 'usable' Go toolchains depend on go-bootstrap-native.
Signature · 2 lines
Maciej Borzecki RnDity