Hi, I am not sure whether the problem really is a sandbox bug but I'll just post it here for future reference anyway, feel free to close it immediately ;) When faced with the problem of insufficient RAM on my router to compile gcc-4.1.1 on one of my machines (and lack of a build-chroot anywhere), I decided to try and take a rather "different" approach: I mounted router:/ to desktop:/root/chroot I then (bind-)mounted /proc, /dev, /sys, /usr/portage and /var/tmp/portage to the right places in /root/chroot. After that I chrooted in the chroot, did env-update && source /etc/profile When trying to emerge gcc, it bailed out on me claiming: "Link tests are not allowed after GCC_NO_EXECUTABLES.". After googling a bit, I found that it could be related to an older autoconf, so I decided to update that (although it was only a minor revision). While doing that I found the real culprit. When sandbox is enabled, it seems that there are problems with linking against shared libraries: make: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Operation not permitted If I disable sandbox, autoconf builds ands installs just fine. Like I said, this may not be a real sandbox bug, because sshfs has its own quirks. I tried several options to sshfs to resolve the problem. If you have any ideas or pointers on where the problem may be located and if it should be posted upstream, I'd be happy to do that.
that doesnt really look like a sandbox bug
I have yet to compile gcc succesfully, even without sandbox. But I don't get the mentioned error any more, so there must be something related to the problem, but I suspect it can be blamed on sshfs. This is costing me more time then I'd like and I probably will just move the HD to another system or create a build-root for it. Consider this bug as a heads-up for people running into similar problems in the future ;)
Not reproducible, closing.
