snail (10.0.0.11) is a NetBSD-1.6.2/i386 Pentium II 300MHz machine.
cheetah (10.0.0.12) is a NetBSD-1.6.2/i386 Athlon XP+ 2GHz machine
with 2BG of RAM.

On both machines, I installed devel/distcc from pkgsrc.  On snail, I
added the following lines to /etc/mk.conf:

	PKGSRC_COMPILER=	ccache distcc gcc
	DISTCC_HOSTS=		cheetah localhost

On cheetah, I made sure that the compiler was in the PATH, and then
ran distccd.  I was using the default system compiler, so I made sure
that /usr/bin was in my PATH since distccd searches the PATH with which
it was invoked to find the compiler:

	PATH=/usr/bin:${PATH}; export PATH
	distccd --listen 10.0.0.12

This runs distccd as a standalone daemon and binds it to the default
distcc port on 10.0.0.12.  The "--listen addr" seems to be necessary
to make it listen for IPv4 traffic.

Now, when I build packages on snail, the compile jobs are forwarded
to cheetah and the compiled object files are returned back to snail
for subsequent linking.

		*	*	*

Now, this example isn't very interesting.  A more interesting setup
would be if snail were a NetBSD-1.6.2/hpcmips host.  Then on cheetah,
one could checkout the netbsd-1-6 branch of src and build a hpcmips
cross-toolchain using something like:

	cd src; ./build.sh -m hpcmips -t -T /var/tools/hpcmips

And create some symlinks with something like:

	cd /var/tools/hpcmips/bin
	ln -sf hpcmips--netbsdelf-gcc gcc
	ln -sf hpcmips--netbsdelf-gcc cc
	ln -sf hpcmips--netbsdelf-g++ g++
	ln -sf hpcmips--netbsdelf-g++ c++

Then execute distccd with something like:

	PATH=/var/tools/hpcmips/bin:${PATH}; export PATH
	distccd --listen 10.0.0.12

Now, building packages on snail should still cause jobs to be forwarded
to cheetah, but those jobs should be compiled using the cross-compiler
in /var/tools/hpcmips.  I'd appreciate it very much if someone could
actually test this type of cross-compile setup using real machines and
let mek know if this actually works in real life.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>