distcc and alfs
gerard at linuxfromscratch.org
Fri Feb 18 09:14:05 PST 2005
Have any of you incorporated distcc in ALFS profiles? I had begun work on this
a while back and was working on it off to make sure the build is always done
in "pure" fashion so to speak.
Then my laptop died and I thought I had the files and test profiles copied to
my main server. Apparently that alfs stuff was the only thing I stored in the
wrong place so that's lost for now. The laptop's drive is fine, just the IDE
controller. So when i get my hands on a laptop I can copy my files off of it
In the mean time, this is what I remember what I came up with and I'd like to
run it by you guys and see if it sounds stable and reasonable.
The process assumes that all systems volunteering are LFS systems that are
installed using the current LFS methodology. This way it's guaranteed the
toolchains on the remote systems are sane and match the one of the
The host system that is being using in chapter 5 could be an already proper
LFS system (including an lfs livecd) but it could also be any other kind of
system so I don't trust to use distcc yet to play it safe.
To that end binutils-pass1 and gcc-pass1 will be compiled the regular way
without bringing in remote systems into the picture.
Next, start a new distccd process and run it on an alternate port so it
doens't interfere with another distccd process that we may not want to kill.
I picked port 50000 but it doesn't really matter. Just pick one and stick
Now user "lfs" can setup distcc's host file and add:
"localhost:50000 remote servers here"
At this point it should be safe to add /usr/lib/distcc to be beginning of user
lfs' $PATH and run the rest of chapter 5.
At the end of chapter 5 you'd want to build distcc as well so it is available
in chapter 6 inside chroot.
When you're finished with chapter 5, kill the running distccd on port 50000.
Enter chapter 6 and chroot and setup the distcc host file for "root." You'll
have to use ip addresses for the time being. Start a new distccd on a new
port, say 60000. You could reuse port 50000 again if you make 100% sure the
old distccd was actually killed.
Start building chapter 6 and all should be well, save the occasional alternate
installation quirk for those packages that aren't too happy with parellell
One thing I hadn't gotten around to testing yet is if distccd does any path
hashing. When GCC is installed in chapter 6, /usr/lib/distcc would need to be
updated and the symlinks there point to the new locations
(from /tools/bin/gcc to /usr/bin/gcc for instance). I don't know if distccd
reads these symlinks every time a compile job is scheduled. If it doesn't, a
SIGHUP or an actuall kill+restart of distccd would be in order after chapter
6's GCC is installed.
I think that's about it. I may have forgotten a few things here and there due
to missing notes.
How does it sound in general though?
/* If Linux doesn't have the solution, you have the wrong problem */
More information about the alfs-discuss