Re: Building go packages: Is "__arch_install_post export NO_BRP_STRIP_DEBUG=true" still needed?
From: Johannes Kastl Sent: Tuesday, April 18, 2023 01:16 To: packaging@lists.opensuse.org Subject: Re: Building go packages: Is "__arch_install_post export NO_BRP_STRIP_DEBUG=true" still needed?
Morning Richard, On 18.04.23 at 10:08 Richard Biener wrote:
ISTR that Go requires functional backtrace() for quite some of its functionality (which users expect to work) and without debug info the quality of that is severely degraded. So to check you'd have to actually run built go packages, compiling isn't good enough.
Sorry, I was unclear. I executed the binary, at least the "version" part and it did not crash or segfault.
Hello Johannes, I looked into this again after seeing your initial email in this thread. Yes, it may now be possible to remove NO_BRP_STRIP_DEBUG with currently supported versions of openSUSE and SLE. Further testing is needed before making a general recommendation. I will continue investigating and update in this thread with the results. Some background for those interested: In 2016, https://bugzilla.opensuse.org/show_bug.cgi?id=964546 reported errors on Go binaries built in OBS manifesting as: fmt.a: go archive is missing __.PKGDEF Aleksa Sarai reported https://github.com/golang/go/issues/17890. Summarizing, GNU strip circa 2016 would incorrectly strip .a archives output by the Go compiler and write out a modified invalid archive instead of exiting with error and leaving the .a file unchanged. Aleksa closed the upstream issue and created https://github.com/openSUSE/brp-check-suse/pull/7 to revert stripping if strip outputs to stderr. This was not merged, so if the issue was fixed by subsequent changes in brp-check-suse change or binutils it would be best to document those minimum versions in our Go packaging guidance, as well as the current state of GNU strip with Go binaries. In the time since 2016, Go packages use the spec comment "# nodebug" and %define __arch_install_post export NO_BRP_STRIP_DEBUG=true. These may no longer have any effect today, so removal will be tested. I am starting testing with vale (a grammar checker) at https://build.opensuse.org/request/show/1080075 which executes the binary --help in the %check section for platform and repository coverage. We will need to test CGo enabled applications as well. To address the golang-packaging question from your initial email: golang-packaging has the macro go_nostrip to undefine _build_create_debug and define NO_BRP_STRIP_DEBUG as above. go_nostrip is one of the only macros from the original golang-packaging that is still useful today with Go modules. Much of the golang-packaging functionality automates complex file movements that populate the file tree under GOPATH with declared dependencies, obsolete when working with Go modules. Jeff Jeff Kowalczyk Software Engineer, Go Developer Experience SUSE Linux http://suse.com
Hi Jeff, On 18.04.23 at 12:16 Jeff Kowalczyk wrote:
I looked into this again after seeing your initial email in this thread. Yes, it may now be possible to remove NO_BRP_STRIP_DEBUG with currently supported versions of openSUSE and SLE. Further testing is needed before making a general recommendation. I will continue investigating and update in this thread with the results.
Thank you very much for your reply and for investigating. No hurry, there are dozens of packages using this, so it will take time to phase this out. [long explanation with lots of interesting details] Thanks for the explanation on the background.
To address the golang-packaging question from your initial email:
golang-packaging has the macro go_nostrip to undefine _build_create_debug and define NO_BRP_STRIP_DEBUG as above.
go_nostrip is one of the only macros from the original golang-packaging that is still useful today with Go modules. Much of the golang-packaging functionality automates complex file movements that populate the file tree under GOPATH with declared dependencies, obsolete when working with Go modules.
That means the Packaging_go page in the wiki needs a big overhaul? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (2)
-
Jeff Kowalczyk
-
Johannes Kastl