Summary: | dev-lang/go: gcc-386-freebsd-exec forces 32-bit glibc libs to be perpetually preserved | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | kfm |
Component: | Current packages | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=687492 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
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. |
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.