First, basic definitions.
distcc ==> compile on machine A for machine B. No mention of whether
the processors are different architectures.
cross-compile ==> compile under architecture A for architecture B
I'm trying to run a distccserver in a 32-bit VM on a 64-bit host, for
the benefit of my ancient 32-bit-only netbook. Yeah, "it'll work" using
the native 64-bit host OS. But any stuff that links against 32-bit
libraries is going to be sent back to the netbook to compile locally.
That defeats the whole purpose of distcc. This is why I want the 32-bit
VM to compile for the 32-bit Atom. Here's the launch script for the
32-bit VM on the i3 machine...
#!/bin/bash
qemu-system-i386 -enable-kvm \
-cpu host -display gtk \
-drive file=gentoo32.img,format=raw \
-drive file=linuxswap.img,format=raw \
-net nic,model=virtio \
-rtc base=localtime,clock=host \
-net
user,hostname=gentoovm,hostfwd=tcp::2022-:22,hostfwd=tcp::3632-:3632,hostfwd=udp::3632-:3632
\
-m 3G -name "Gentoo VM" \
-parallel none \
${@}
Amongst other things, it forwards port 3632 destined for the host, to
the VM. "ssh -p 2022 root@192.168.123.249" works from the Atom to the
VM. I get an ssh teminal. There's no iptables blocking things, and
distccd is running on the VM (it's in the default rc-update level). Yet
the Atom spits out stuff like...
distcc[8248] (dcc_pump_sendfile) ERROR: sendfile failed: Broken pipe
distcc[8248] (dcc_writex) ERROR: failed to write: Broken pipe
distcc[8248] Warning: failed to distribute shell.c to
192.168.123.249/6,lzo,cpp, running locally instead
...when trying to outsource the compile. What am I doing wrong?
--
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications
