On Sat, 2 Jan 2016 10:42:31 +0000 Neil Bothwick wrote: > On Fri, 1 Jan 2016 22:11:34 -0500, waltd...@waltdnes.org wrote: > > > 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... > > I used to take a different approach. Instead of a VM I used a chroot > that was a clone of the netbook, except that make.conf in the chroot > included buildpkg in FEATURES and the netbook's make.conf have --usepkg in > DEFAULT_OPTs. PKGDIR was an NFS share accessible to both.
Similar solution here, but instead of cloning, I NFS-mount root
from slow system using filescached to speedup I/O process and
placing all volatile data (/tmp, /var/tmp) either in local memory
or on fast local storage. This way there is no need to make manual
modifications twice or synchronize them somehow (e.g. when
modification of package.use or package.license during update is
needed).
I must warn that such approach should not be used for packages
using build-time profiling, like sci-libs/atlas or any ebuild with
USE="pgo" enabled; otherwise profiling will be wrong and targeted
on helper system instead of target box. In such cases distcc may be
used.
For 32-bit distcc on 64-bit host there is no need to chroot or
create VM (hey, they're hellishly slow!). Just add -m32 to your
*FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
{C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
can be worked around on distcc server by forcing -m32 for each
gcc call.
Best regards,
Andrew Savchenko
pgpDx8p1e6tpV.pgp
Description: PGP signature
