This bug report is a request that parallel operations in distcc or distcc-pump be disabled in the package makefile for all packages that break the build. My priority packages are those used to build to xfce4, gnome and kde bootable systems. https://wiki.gentoo.org/wiki/Distcc Some packages do not use distcc As various packages are installed, users will notice that some of them aren't being distributed (and aren't being built in parallel). This may happen because the package' Makefile doesn't support parallel operations, or the maintainer of the ebuild has explicitly disabled parallel operations due to a known problem. Sometimes distcc might cause a package to fail to compile. If this happens, please report it. Report: Failed package compiles in distcc or distcc-pump include, but are not limited to, the following from a KDE build :- llvm libvpx taglib exiv2 kbuild virtualbox-guest-additions xf86-video-virtualbox ffmpeg kjs kcoreaddons freerdp openal I believe there will be more failures in Gnome. The failures are repeatable across about twenty builds. The fix for all failures is to compile in gcc. The situation in a new build is so bad that I have copied the /etc/portage/make.conf file three times and added three cases :- Case 1: MAKEOPTS=”-j24 -l4” FEATURES=”distcc distcc-pump” Case2: MAKEOPTS=”-j24 -l4” FEATURES=”distcc” Case3: MAKEOPTS=”-j4” I can then more quickly change between cases after each break by :- cd /etc/portage rm make.conf && ln -s make.conf3 make.conf #Compile with gcc or #1 for distcc-pump emerge …. kde-meta The first 250 packages of about 700 to build the kde-meta build in Case 1 go in unattended. Thereafter random failures need constant attention and defeat the purpose of using distcc which is to save considerable amounts of time. Miscompiling under distcc and distcc-pump also seems to be a concern but I have found no evidence of it getting into the build after about twenty new builds. Kernels built with genkernel –kernel-cc=”distcc” --utils-cc=”distcc” --makeopts=”j24 -l4” have shown no obvious faults. The build system consists of four VirtualBox VMs with four CPUs in each. A Gentoo stage3systemd download forms the basis of the first machine. A bootable kernel was compiled and distcc emerged. This image was exported/cloned to form four identical VMs, although the hardware CPUs are different. Three of the machines are distccd servers that are identical to the build system basic install, so no mismatches in build environments that would cause failures in distcc is expected .
distcc-pump is a cheap hack made by the G. company for their own use. It is horribly broken everywhere else and they don't care to fix it. Don't *ever* use it. If you used it, you may end up with half-broken packages installed (yes, it also causes silent miscompilings). distcc is safe for use everywhere. I'm using it for years now and never had an issue related directly to it. The only issues you might have are either related to distcc-pump (see above) or bug #581880 which is fixed by chown-ing the directory. If you have any other issue, please report specific bugs. However, I'm afraid that could only be misconfiguration (such as using -march=native or having incompatible gcc versions).
