This issue was discovered in the course of switching an installation from a multilib profile to a non-multilib profile, where dev-lang/go was already installed. Specifically, I switched from "default/linux/amd64/17.1/hardened" to "default/linux/amd64/17.1/no-multilib/hardened". I then ran emerge -auUD @world, which covers glibc as a result of the multilib flag being masked. After finishing with glibc, portage reported the following preserved-libs. >>> package: sys-libs/glibc-2.27-r6 * - /lib/ld-2.27.so * - /lib/ld-linux.so.2 * - /lib/libc-2.27.so * - /lib/libc.so.6 * used by /usr/lib/go/src/debug/elf/testdata/gcc-386-freebsd-exec (dev-lang/go-1.10.3) Naturally, the proposition to emerge @preserved-rebuild does not result in these libraries being cleaned up and removed. I'm uncertain as to how gcc-386-freebsd-exec fits into the golang toolchain as a whole. If it is genuinely required then I think that the ebuild needs to express that requirement by coercing the use of a multilib-enabled glibc. Impeding the use of a no-multilib profile would be a costly outcome, however. Better still would be to avoid the installation of gcc-386-freebsd-exec for no-multilib systems, if to do so would not unduly compromise the functionality of the toolchain.
It is quite possible that all files in /usr/lib/go/src/debug are unnecessary for production usage, but to be safe I use this workaround: # cat /etc/portage/env/dev-lang/go post_pkg_postinst () { rm -f /usr/lib/go/src/debug/elf/testdata/gcc-386-freebsd-exec sed -i '/gcc-386-freebsd-exec/d' /var/db/pkg/dev-lang/go-1.12.15/CONTENTS }
I'm also experiencing this with go-1.13.8 after switching to the default/linux/amd64/17.1/no-multilib/hardened profile.
This is fixed in go-1.14.2. by removing the testdata directories from the installation.
