toolbox/toolbox-Make-the-build-flags-match-Fedora-s-gobuild-for-PPC64.patch

64 lines
2.3 KiB
Diff
Raw Normal View History

2021-12-10 03:46:24 +00:00
From 32aa30a17358598f568991a5375f6182e4135648 Mon Sep 17 00:00:00 2001
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
From: Debarshi Ray <rishi@fedoraproject.org>
Date: Mon, 29 Jun 2020 17:57:47 +0200
Subject: [PATCH] build: Make the build flags match Fedora's %{gobuild} for
PPC64
The Go toolchain doesn't play well with passing compiler and linker
flags via environment variables. The linker flags require a second
level of quoting, which leaves the build system without a quote level
to assign the flags to an environment variable like GOFLAGS.
This is one reason why Fedora doesn't have a RPM macro with only the
flags. The %{gobuild} RPM macro includes the entire 'go build ...'
invocation.
The Go toolchain also doesn't like the LDFLAGS environment variable as
exported by Fedora's %{meson} RPM macro.
Note that these flags are only meant for the "ppc64" CPU architecture,
and should be kept updated to match Fedora's Go guidelines. Use
'rpm --eval "%{gobuild}"' to expand the %{gobuild} macro.
---
2021-12-10 03:46:24 +00:00
src/go-build-wrapper | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
diff --git a/src/go-build-wrapper b/src/go-build-wrapper
2021-12-10 03:46:24 +00:00
index ef4aafc8b024..f8ea8370792c 100755
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
--- a/src/go-build-wrapper
+++ b/src/go-build-wrapper
2021-12-10 03:46:24 +00:00
@@ -32,9 +32,9 @@ if ! cd "$1"; then
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
exit 1
fi
2021-12-10 03:46:24 +00:00
-tags=""
+tags="-tags rpm_crashtraceback,${BUILDTAGS:-}"
if $6; then
- tags="-tags migration_path_for_coreos_toolbox"
+ tags="$tags,migration_path_for_coreos_toolbox"
fi
if ! libc_dir=$("$4" --print-file-name=libc.so); then
@@ -69,11 +69,16 @@ fi
dynamic_linker="/run/host$dynamic_linker_canonical_dirname/$dynamic_linker_basename"
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
+unset LDFLAGS
2021-12-10 03:46:24 +00:00
+
# shellcheck disable=SC2086
go build \
+ -compiler gc \
$tags \
- -trimpath \
- -ldflags "-extldflags '-Wl,-dynamic-linker,$dynamic_linker -Wl,-rpath,/run/host$libc_dir_canonical_dirname' -linkmode external -X github.com/containers/toolbox/pkg/version.currentVersion=$3" \
+ -ldflags "${LDFLAGS:-} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') -compressdwarf=false -extldflags '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-dynamic-linker,$dynamic_linker -Wl,-rpath,/run/host$libc_dir_canonical_dirname' -linkmode external -X github.com/containers/toolbox/pkg/version.currentVersion=$3" \
+ -a \
+ -v \
+ -x \
-o "$2/toolbox"
2021-12-10 03:46:24 +00:00
exit "$?"
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00
--
2.31.1
Update to 0.0.91 Toolbox is now written in Go, so this is no longer a noarch package. Unlike idiomatic Go code-bases, Toolbox uses the Meson build system to check for additional non-Go dependencies and install various auxilliary files. This leads to some interesting problems. The Go toolchain doesn't play well with passing compiler and linker flags via environment variables. The linker flags require a second level of quoting, which leaves the build system without a quote level to assign the flags to an environment variable like GOFLAGS. This is one reason why Fedora doesn't have a RPM macro with only the flags. The %{gobuild} RPM macro includes the entire 'go build ...' invocation. Therefore, the entire 'go build ...' invocation is swapped out using a set of downstream patches (one for PPC64 because it doesn't use '-buildmode pie', and another for other CPU architectures) to match the %{gobuild} RPM macro. The Go toolchain also doesn't like the LDFLAGS environment variable as exported by Fedora's %{meson} RPM macro. For some reason, when built on Koji, the final binary gets created as ../src/src instead of ../src/toolbox, but it doesn't happen when building locally with 'rpmbuild -ba ...'. Hence it's necessary to explicitly specify the name of the output binary. Finally, Fedora doesn't support Go modules when building Go programs. This means that Go's semantic import versioning can't be used. A conscious effort was made to minimize the use of exotic Go-specific RPM macros to retain the legibility of the spec file. A proliferation of such RPM macros is a hindrance for those who are not experts in the ins and outs of packaging Go code in Fedora. Some changes by Debarshi Ray. https://src.fedoraproject.org/rpms/toolbox/pull-request/2
2020-06-30 17:17:15 +00:00