rpms/toolbox
7
0
Fork 0
Code Issues Pull Requests Releases Activity
0ad2c75c04
toolbox/toolbox-Make-the-build-flags-match-Fedora-s-gobuild.patch

55 lines
2.0 KiB
Diff
Raw Normal View History

Update the commit messages of the downstream patches Fedora now has a %{gobuildflags} RPM macro with only the flags used by 'go build ...'. There's no need to do a build just for this.
2023-04-03 21:15:51 +00:00
From f4582e4748a15c462eac229f9bd9214415f166c9 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
Update the commit messages of the downstream patches Fedora now has a %{gobuildflags} RPM macro with only the flags used by 'go build ...'. There's no need to do a build just for this.
2023-04-03 21:15:51 +00:00
Subject: [PATCH] build: Make the build flags match Fedora's %{gobuildflags}
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
Update the commit messages of the downstream patches Fedora now has a %{gobuildflags} RPM macro with only the flags used by 'go build ...'. There's no need to do a build just for this.
2023-04-03 21:15:51 +00:00
The Go toolchain doesn't like the LDFLAGS environment variable as
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
exported by Fedora's %{meson} RPM macro.
Note that these flags are meant for every CPU architecture other than
PPC64, and should be kept updated to match Fedora's Go guidelines. Use
Update the commit messages of the downstream patches Fedora now has a %{gobuildflags} RPM macro with only the flags used by 'go build ...'. There's no need to do a build just for this.
2023-04-03 21:15:51 +00:00
'rpm --eval "%{gobuildflags}"' to expand the %{gobuildflags} macro.
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
---
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
src/go-build-wrapper | 14 ++++++++++----
1 file changed, 10 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
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
index c572d6dfb02b..0e6a2efa6853 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
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
@@ -33,9 +33,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
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
-tags=""
+tags="-tags rpm_crashtraceback,${BUILDTAGS:-}"
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
if $7; then
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
- tags="-tags migration_path_for_coreos_toolbox"
+ tags="$tags,migration_path_for_coreos_toolbox"
fi
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
if ! libc_dir=$("$5" --print-file-name=libc.so); then
@@ -70,11 +70,17 @@ fi
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
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
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
+
# shellcheck disable=SC2086
go build \
+ -buildmode pie \
+ -compiler gc \
$tags \
- -trimpath \
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
- -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=$4" \
+ -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 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dynamic-linker,$dynamic_linker -Wl,-rpath,/run/host$libc_dir_canonical_dirname' -linkmode external -X github.com/containers/toolbox/pkg/version.currentVersion=$4" \
Update to 0.0.99.3
2021-12-10 03:46:24 +00:00
+ -a \
+ -v \
+ -x \
Update to 0.0.99.4 https://bugzilla.redhat.com/show_bug.cgi?id=2171961
2023-02-21 15:42:39 +00:00
-o "$2/$3"
Ensure that binaries are run against their build-time ABI https://bugzilla.redhat.com/show_bug.cgi?id=1995439
2021-10-22 00:17:56 +00:00
Update to 0.0.99.3
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
--
Update the commit messages of the downstream patches Fedora now has a %{gobuildflags} RPM macro with only the flags used by 'go build ...'. There's no need to do a build just for this.
2023-04-03 21:15:51 +00:00
2.39.2
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
Reference in New Issue Copy Permalink