Created attachment 850386 [details, diff] patch to ignore linker workarounds See https://github.com/golang/go/blob/261fe25c83a94fc3defe064baed3944cd3d16959/src/cmd/link/internal/ld/lib.go#L1554 Go forces the linker for various target combinations. Most importantly, it forces gold on arm / arm64 because of a deficiency in bfd that got fixed years ago. See https://sourceware.org/bugzilla/show_bug.cgi?id=19962 This got fixed in binutils 2.36. Furthermore, since we are deprecating gold, this may prevent golang working on arm / arm64 at all. Upstream has a PR https://github.com/golang/go/pull/49748 , but I don't think we should adopt it as it still uses gold, which is something we want to avoid alltogether. I'd suggest we just bypass this "linker workaround detection logic" alltogether, see the attached patch. The behaviour in this case is to just invoke CC for linking without a -fuse-ld override.
I would rather avoid carrying a distro-specific patch if possible. Can you open an issue upstream and link it here please? Thanks, William
NVM I'll add a link in the upstream pr to this bug. William
See https://github.com/golang/go/issues/22040#issuecomment-1429137580. I don't think we can do anything here yet, given Go tests fail when using bfd.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cd6e76e6b88427411c8c1e8aab9204abc4acdf8c commit cd6e76e6b88427411c8c1e8aab9204abc4acdf8c Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2023-02-15 00:59:07 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2023-02-15 00:59:07 +0000 dev-lang/go: make sure gold is available on arm/arm64 Bug: https://bugs.gentoo.org/893956 Signed-off-by: William Hubbs <williamh@gentoo.org> dev-lang/go/go-1.19.6.ebuild | 3 +++ dev-lang/go/go-1.20.1.ebuild | 3 +++ 2 files changed, 6 insertions(+)
Given that gold is essentially dead code, this may cause trouble down the road.
According to the upstream issue this should be fixed now with binutils 2.41.
(In reply to Jan Breig from comment #6) > According to the upstream issue this should be fixed now with binutils 2.41. Right, the problem is Go itself needs to learn that.
(In reply to Sam James from comment #7) > (In reply to Jan Breig from comment #6) > > According to the upstream issue this should be fixed now with binutils 2.41. > > Right, the problem is Go itself needs to learn that. https://go-review.googlesource.com/c/go/+/391115 It mostly hangs right now because Go's ci still uses binutils 2.40 and errors out with the patch ... /o\