go has a feature of workspaces [1]. If there is a file called go.work
in your working directory on any of its parent directories that will
be read and used during build. For OE where the builds shall
be sandboxed this is bad as a workspace file outside of the build
environment can be picked up. This commit wil disable that feature
according to the instruction in [1].
This was found and introduced build failures when a file go.work was
in the parent directory outside of OE build directory.
[1] https://go.dev/ref/mod#workspaces
(From OE-Core rev: 9538bcefab6881805d60d9f362e0b70996b5e2f9)
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: c52c5e88626968b08510818f09829f2e1c9f94ae)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
When cgo is enabled, the Go toolchain writes temporary source files
(*.c) under GOTMPDIR and compiles them there. when -trimpath is passed
to go, Go passes options such as
-ffile-prefix-map=$WORK/b387=/tmp/go-build internally to the GCC
instance it invokes. The variable WORK is a temporary directory created
under GOTMPDIR, refer the following log:
[snip of compile log]
WORK=/build/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/build-tmp/go-build377321751
cd $WORK/b387
TERM='dumb' x86_64-wrs-linux-gcc -m64 -march=x86-64-v3 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/recipe-sysroot -I /tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/sources/buildah-1.41.5/src/github.com/containers/buildah/vendor/github.com/proglottis/gpgme -fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=$WORK/b387=/tmp/go-build -gno-record-gcc-switches -v -D_FILE_OFFSET_BITS=64 -I $WORK/b387/ -O2 -g -ffile-prefix-map=/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/sources/buildah-1.41.5=/usr/src/debug/buildah/1.41.5 -ffile-prefix-map=/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/build=/usr/src/debug/buildah/1.41.5 -ffile-prefix-map=/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/recipe-sysroot= -ffile-prefix-map=/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/recipe-sysroot-native= -pipe -v -ffile-prefix-map=/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/sources/buildah-1.41.5/src/github.com/containers/buildah/vendor=/_/vendor -frandom-seed=TZkSPVSBUvDMjg4wKjWS -o $WORK/b387/_x004.o -c unset_agent_info.cgo2.c
[snip of compile log]
OE also passes its own DEBUG_PREFIX_MAP to GCC(finally by CGO_CFLAGS),
including -ffile-prefix-map=${B}=${TARGET_DBGSRC_DIR}, where B is
${WORKDIR}/build. Because GOTMPDIR defaults to ${WORKDIR}/build-tmp, the
Go temporary directory looks like ${WORKDIR}/build-tmp/go-buildXYZ. Its
prefix therefore begins with ${WORKDIR}/build, so GCC matches the
DEBUG_PREFIX_MAP entry for ${B} first.
As a result, a path such as ${WORKDIR}/build-tmp/go-buildXYZ is
rewritten to ${TARGET_DBGSRC_DIR}-tmp/go-buildXYZ. This breaks the
-ffile-prefix-map option that Go itself adds, because the original WORK
path no longer matches the value Go expects. Since Go creates
go-buildXYZ directories randomly and internally, this causes the build
non-reproducible.
This patch changes GOTMPDIR from ${WORKDIR}/build-tmp to
${WORKDIR}/tmp-go-build so that the path no longer matches ${B}. This
prevents unintended replacements by OE's DEBUG_PREFIX_MAP and
restores reproducibility.
Note that pure go program like go-helloworld under OE will not have this
issue since it doen't use cgo, it is reproducible without this fix
(From OE-Core rev: 1b08bf9296fb6583234933b22b67b851591610a8)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 0642d2323072f561a4d0eeb9266213387b2997fc)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
This will make possible to restore the default dynamic linking globally
which is what we had before the 1.20.X release.
(From OE-Core rev: 941c8535eaaca5790c9bc2b3d21d8ce402dbb431)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6ad90fc2fc49c4199a59dfb1c1d81a7ba184a522)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The GOPROXY is already correctly defined on the native sys root
and this can be checked using the bitbake devshell:
| $ go env GOPROXY
| https://proxy.golang.org,direct
The go_do_compile task calls the compiler directly so the
GOPROXY env is not seen because it's not defined in the shell.
Defining it explicitly solves this problem and was to avoid
setting it in the recipes itself.
(From OE-Core rev: e0919a3f7bc26b1ea9fb57740de4a9a3b9253f26)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is little point in having "crosssdk" suffex added to the virtual provider within
gcc/go since the TARGET_PREFIX or SDK_PREFIX already encapsulates this. Remove it
allowing some of the special case overriding to be removed.
This also allows removal of some of the MLPREFIX usage since again, the triplet
also covers this.
(From OE-Core rev: fe0206ba482d209b24e636d578aa68ba5e67ba1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Peter Bergin
Changqing Li
Jose Quaresma
Martin Jansa
Richard Purdie