1 |
On 2 January 2016 11:56:58 GMT+00:00, Andrew Savchenko <bircoph@g.o> wrote: |
2 |
> On Sat, 2 Jan 2016 10:42:31 +0000 Neil Bothwick wrote: |
3 |
> > On Fri, 1 Jan 2016 22:11:34 -0500, waltdnes@××××××××.org wrote: |
4 |
> > |
5 |
> > > I'm trying to run a distccserver in a 32-bit VM on a 64-bit |
6 |
> host, for |
7 |
> > > the benefit of my ancient 32-bit-only netbook. Yeah, "it'll work" |
8 |
> using |
9 |
> > > the native 64-bit host OS. But any stuff that links against |
10 |
> 32-bit |
11 |
> > > libraries is going to be sent back to the netbook to compile |
12 |
> locally. |
13 |
> > > That defeats the whole purpose of distcc. This is why I want the |
14 |
> 32-bit |
15 |
> > > VM to compile for the 32-bit Atom. Here's the launch script for |
16 |
> the |
17 |
> > > 32-bit VM on the i3 machine... |
18 |
> > |
19 |
> > I used to take a different approach. Instead of a VM I used a chroot |
20 |
> > that was a clone of the netbook, except that make.conf in the chroot |
21 |
> > included buildpkg in FEATURES and the netbook's make.conf have |
22 |
> --usepkg in |
23 |
> > DEFAULT_OPTs. PKGDIR was an NFS share accessible to both. |
24 |
> |
25 |
> Similar solution here, but instead of cloning, I NFS-mount root |
26 |
> from slow system using filescached to speedup I/O process and |
27 |
> placing all volatile data (/tmp, /var/tmp) either in local memory |
28 |
> or on fast local storage. This way there is no need to make manual |
29 |
> modifications twice or synchronize them somehow (e.g. when |
30 |
> modification of package.use or package.license during update is |
31 |
> needed). |
32 |
> |
33 |
> I must warn that such approach should not be used for packages |
34 |
> using build-time profiling, like sci-libs/atlas or any ebuild with |
35 |
> USE="pgo" enabled; otherwise profiling will be wrong and targeted |
36 |
> on helper system instead of target box. In such cases distcc may be |
37 |
> used. |
38 |
> |
39 |
> For 32-bit distcc on 64-bit host there is no need to chroot or |
40 |
> create VM (hey, they're hellishly slow!). Just add -m32 to your |
41 |
> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores |
42 |
> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this |
43 |
> can be worked around on distcc server by forcing -m32 for each |
44 |
> gcc call. |
45 |
> |
46 |
> Best regards, |
47 |
> Andrew Savchenko |
48 |
|
49 |
I tried that too. I stuck with containers because I could have a script that rsynced /etc/portage with the slow machine and then entered the container and ran emerge @world. That script ran on the build host in the early hours, after the host had run emerge - - sync, so by the time I crawled out of bed, all the packages were ready to install, without requiring the slow machines to even be running. |
50 |
-- |
51 |
Sent from my Android phone with K-9 Mail. Please excuse my brevity. |