Arch Linux

Uh, can we have something a little more concrete than "it feels wrong"?

1) Are you sure the makepkg.conf is -- still -- properly configured?
2) What does g/cc actually resolve to inside the chroot? This is trivially confirmed by running 'type -a gcc' in the PKGBUILD build function.
3) Set distcc's own $DISTCC_VERBOSE environment variable to like actually get information about its running.
4) Try to provide some vaguely minimal form of useful information in your bug reports other than "it doesn't work".

Thanks for the reply and feedback, eschwartz.

1) Yes, I am sure. The attached is ~/.chroot64/facade/etc/makepkg.conf (filename=makepkg.conf)
2) Adding `type -a gcc` into the PKGBUILD returns the following and run from the makechrootpkg command:
gcc is /usr/lib/distcc/bin/gcc
gcc is /usr/bin/gcc

For reference, I also am attaching the PKGBUILD I am using to reproduce the issue (filename=PKGBUILD)

3) I edited the server's /etc/conf.d/distccd to contain: DISTCC_ARGS="--allow 10.9.8.0/24 --log-file /tmp/distccd.log --verbose" and also added `export DISTCC_VERBOSE=1` in the PKGBUILD itself. When running the build, I am seeing tons of messages about distcc lock files being busy with the verbose switch. Find the output attached (filename=linux-4.17.8-1-x86_64-build.log.xz)
As well, I added the server log which interestingly doesn't contain any info beyond the initial entries. (filename=distccd.log)
4) Without the verbose switches you recommended, I found nothing diagnostic in dmesg/journalctl or in distccd.log, so the best I could do is report the differences in compile time. Thanks again for the direction and helpful suggestions.

Is there anything the devtool scripts would be setting up that would block or redirect calls to the localhost distccd?

I cannot imagine so, it just runs systemd-nspawn with some directories bind-mounted plus --register=no --keep-unit --as-pid2

The interesting thing is distcc in the makepkg execution is reporting:
distcc[4501] (dcc_parse_hosts) found localhost token "localhost/9"
distcc[4501] (dcc_parse_hosts) found tcp token "waste/9"
distcc[4501] (dcc_parse_hosts) found tcp token "relic/5"
distcc[4501] (dcc_parse_hosts) found tcp token "myth2/5"

Which indicates it correctly detected your build slaves, or at least that's what I assume a token is.

And then there *are* lines like:

distcc[5411] exec on waste/9: gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-var-tracking-assignments -pg -mfentry -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -c -o arch/x86/platform/efi/.tmp_quirks.o arch/x86/platform/efi/quirks.c

But they're outnumbered by the ones to localhost...

@eschwartz - Agreed. It's definitely something in the chroot. I can reproduce it on any node on the network: 1) building outside of the chroot works as expected and 2) building in the chroot gives tons of "(dcc_lock_host) /build/.distcc/lock/cpu_xxx is busy" lines and 5-6x slow down in compile times. What ever is causing it, it is somewhat recent (ie past 4-6 weeks). I have been building in the chroot with distcc for years without issue.

I think I tracked this issue to down to the fact that hostname resolution is broken from within the chroot. If I define the DISTCC_HOSTS variable using IP addresses rather than hostnames, distcc works as expected. Can someone else confirm this to rule out something funny my router is doing?

Probably safe to close. Solution to building linux kernel in a clean chroot is to add the following line to the PKGBUILD before building:

sed -i '/HAVE_GCC_PLUGINS/d' arch/x86/Kconfig