The ebuild is trying to build LXD inside the GOROOT (/usr/lib64/go) instead of the local GOPATH in $WORKDIR: >>> Compiling source in /var/tmp/portage/app-emulation/lxd-2.18/work/lxd-2.18 ... make -j2 -s net github.com/lxc/lxd/shared/logger os/user go install os/user: open /usr/lib64/go/pkg/linux_amd64/os/user.a: permission denied github.com/lxc/lxd/shared/api github.com/lxc/lxd/shared/ioprogress github.com/lxc/lxd/shared/osarch github.com/lxc/lxd/vendor/gopkg.in/yaml.v2 github.com/lxc/lxd/shared/gnuflag github.com/lxc/lxd/vendor/github.com/gosexy/gettext go install os/user: open /usr/lib64/go/pkg/linux_amd64/os/user.a: permission denied
The same issue applies to app-emulation/lxd-2.19 too. A good way to avoid these kind of issues is to create a local copy of GOROOT and use it to compile the package; something as follow: src_compile() { # Create a writable GOROOT in order to avoid sandbox violations. cp -sR "$(go env GOROOT)" "${T}/goroot" || die GOROOT="${T}/goroot" golang-build_src_compile rm -rf "${T}/goroot" || die }
Could you please provide a full log of the emerge process? (See https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide ) On my machine, LXD 2.19 build fine.
Created attachment 511176 [details] emerge --info logs
Created attachment 511178 [details] emerge app-emulation/lxd log
> Could you please provide a full log of the emerge process? Sure. > On my machine, LXD 2.19 build fine. Which is irrelevant. Please, don't take this personally, or the wrong way, but the issue I have reported is a very well know bug: https://bugs.gentoo.org/551486 Even if #551486 has been marked closed, it will always re-surface when a Go package needs to directly compile the network component (/usr/lib/go/pkg/linux_amd64/net.a) from the Go standard library. This happens because the golang-* eclasses make wrong assumptions about the Go workspace, violating its specs: https://golang.org/doc/code.html#Workspaces GOROOT (usr/lib64/go) should never be directly tampered by ebuilds in the first place, otherwise you violate Go's compiler determinism. The only way to work around this problem is to have a local copy of GOROOT inside $WORKDIR. This way the ebuild doesn't attempt to violate the sandbox. Right now, I just re-synced portage and re-emerged LXD v2.19 but the issue is still present; then I tried on a new VM with a fresh stage3, and I got the very same issue. At this point, there are two possible explanations why you're successful on your personal machine: 1. you have a screwed up Go's toolchain (most probably /usr/lib64/go/pkg has wrong permissions that allow everyone to write in it); 2. you have globally disabled sandbox features and other useful strict FEATURES which prevent sandbox violations;
>> On my machine, LXD 2.19 build fine. > Which is irrelevant. It's relevant to my request for more information. If I can't reproduce, I can't fix.
I forgot to mention that when using a clean stage3, the issue shows up even earlier (permission problems on the sys pkg of the Go's standard library): >>> Compiling source in /var/tmp/portage/app-emulation/lxd-2.19/work/lxd-2.19 ... make -j1 go install -v -tags libsqlite3 ./... runtime/internal/sys go install runtime/internal/sys: open /usr/lib64/go/pkg/linux_amd64/runtime/internal/sys.a: permission denied make: *** [Makefile:16: default] Error 1 It's the same problem, but on a different Go's internal library: the ebuild is trying to compile _inside_ the GOROOT.
I haven't tried anything yet, but do you think it your problems could have anything to do with your INSTALL_MASK being set to "*.a *.la"?
> could have anything to do with your INSTALL_MASK being set to "*.a *.la"? I have a specific dev-lang/go entry in /etc/portage/package.env. But as I have said, I tried on a clean stage3 too with no avail. "qlist -e go | wc -l" gives me the same number on all my machines and CI nodes, which is 7459. Both user.a and sys.a are present and with correct permissions: > # ls -la /usr/lib64/go/pkg/linux_amd64/os/user.a /usr/lib64/go/pkg/linux_amd64/runtime/internal/sys.a -rw-r--r-- 1 root root 107236 Nov 20 10:45 /usr/lib64/go/pkg/linux_amd64/os/user.a -rw-r--r-- 1 root root 5830 Nov 20 10:45 /usr/lib64/go/pkg/linux_amd64/runtime/internal/sys.a I have already un-installed dev-lang/go and checked for orphan files in /usr/lib64/go/{src,pkg} countless of times, and all the times both src/ and pkg/ sub-directory where empty — actually, there is literally nothing inside /usr/lib64/go/*. The funny thing is that app-emulation/docker, app-emulation/docker-runc, app-emulation/docker-proxy, and app-emulation/containerd are all compiling successfully. Which means the Go's toolchain is working correctly. Indeed, I can successfully compile and install all the ~200 hundred packages from the go-overlay (of which I'm the owner and maintainer). The same goes for pretty much every other Go package within Portage. app-emulation/lxd is the only exception so far.
This is what I've just tried: 1. lxc-create -t gentoo -n test 2. Start the container 3. run "emerge lxd" in the container. 4. It compiled and installed fine As of now, I'm inclined to think that the INSTALL_MASK thing might be a good lead to find the root cause of the compile failure. Will investigate that later.
I've just looked at your go-overlay. It seems to have well-organized eclasses for go. Maybe that the portage tree should integrate it but I don't have enough clout or go-specific knowledge to do that. Maybe that the app-emulation/lxd package would be better maintained out of the portage tree and in the go-overlay? Toffanin, did you try adapting the package to the golang-single eclass? Maybe it works better.
Closing since two devs haven't reproduced the issue, and since the ebuild has changed dramatically since the issue was reported. Toffanin, feel free to re-open if this is still a reproducible problem on current versions.
