Hi guys, 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 again. 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 build-in-progress. 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 with it. 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 compiling. 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? -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
