On 2018-11-07, Matthias Bach
The Packaging Go page in the Wiki [1] recommends to use the %{go_nostrip} macro to prevent issues with Go tooling. However, it is unclear to me whether this recommendation should also be followed for application binaries. After all, the page mostly focuses on the, now deprecated, development packages. For these I fully see the purpose of unstripped binaries. However, for normal applications it seems to me stripping would make sense, as it reduces binary size and it is unlikely people will run tooling on those.
So what's the best practice regarding stripping application binaries?
The best practice is to strip using "go build -s". The reason why we have go_nostrip is because OBS will try to strip binaries to generate debuginfo, and this simply doesn't work with Go binaries (it can break them very badly because GNU strip will happily modify binaries it doesn't understand the structure of -- I submitted some patches for the OBS script to fix this but they weren't accepted for more than a year now). This was a bigger problem with gcc-go, where stripping would result in backtraces being completely broken -- but even with the regular go compiler this is something upstream doesn't support. In particular, the no-strip options are very important for the Go compiler because we ship a bunch of .a files that GNU strip will ruin the metadata of (it changes .__PKGDEF or something like that). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/