Summary: | dev-lang/go build hangs with FEATURES=usersandbox | ||
---|---|---|---|
Product: | Portage Development | Reporter: | matoro <matoro_gentoo> |
Component: | Sandbox | Assignee: | William Hubbs <williamh> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | holger, matoro_gentoo, paolo.pedroni |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | riscv | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=912072 https://bugs.gentoo.org/show_bug.cgi?id=840311 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
matoro
2023-03-01 20:52:57 UTC
I'm updating the title here because despite unsetting PORTAGE_SCHEDULING_POLICY=idle globally, I ran into this issue again with dev-lang/go-1.20.2. After working through everything in FEATURES, I identified that it requires FEATURES=-usersandbox. This works correctly even when PORTAGE_SCHEDULING_POLICY=idle is set. Have no idea what's going on with this - maybe kernel changes? I'm using amd64 and yes, it does hang on "Building Go toolchain1 using /usr/lib/go-bootstrap" It was hanged at "/usr/lib/go-bootstrap/bin/go build -o cmd/dist/dist ./cmd/dist" but I was be able to pass it by removing and installing go-bootstrap package. now it hangs on bulding toolchain. I tried emerging go with FEATURES=-usersandbox and it built succesfully. I have exactly the same problem on my x86_64 freshly installed system (Linux minion 6.1.19-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 10 14:59:39 MSK 2023 x86_64 AMD Ryzen 9 5900HX with Radeon Graphics AuthenticAMD GNU/Linux). Same approach of fixing ("-usersandbox") also helps. Although in my case it's dev-lang/go-1.20.3. Got this problem with the initial installation using both versions of dev-lang/go-boostrap (1.18.6 and ~amd64 1.19.1), have the same problem with the installed go's toolchain afterwards. Thus it's not just riscv, but at least also x86_64. I would like to report the very same problem on ~amd64. Actually in last April, I first experienced this problem. Yet due to my lack of experience and no compilation output (I turned them off), I have no idea what was wrong. Go is being compiled on my machine with a strange cpu load (~1.27, while I gave 12) and from output of htop, only a single core was working. In the following versions of go, this problem appeared from time to time but since I see no one reported it (I once skimmed through bugs of dev-lang/go), I assumed it was my problem perhaps. Even now none of the gentoo users around me has ever experienced this problem. For now, I used `FEATURES=-usersandbox emerge -av1 dev-lang/go` to build it, as suggested in comment 4 above. I'd like to add any further information if needed. Thank you :) This issue seems solved with new go version 1.21.1 amd64. I updated the package without any tinkering. See also: https://bugs.gentoo.org/912072 Not fixed with 1.22. Definitely sandbox- and/or runtime-initialisation related. It may be fixed in recent versions of dev-lang/go. I tried today on a zen4 machine and it worked fine with sandbox and usersandbox. |