1 |
Jonathan Callen <jcallen@g.o> wrote: |
2 |
|
3 |
> -----BEGIN PGP SIGNED MESSAGE----- |
4 |
> Hash: SHA512 |
5 |
> |
6 |
> On 01/02/2016 01:27 PM, waltdnes@××××××××.org wrote: |
7 |
> > On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote |
8 |
> > |
9 |
> >> For 32-bit distcc on 64-bit host there is no need to chroot or |
10 |
> >> create VM (hey, they're hellishly slow!). Just add -m32 to your |
11 |
> >> *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores |
12 |
> >> {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this |
13 |
> >> can be worked around on distcc server by forcing -m32 for each |
14 |
> >> gcc call. |
15 |
> > |
16 |
> > -m32 in a 64-environment works for "Hello World". More complex |
17 |
> > code that requires arch-specific headers and libs will have |
18 |
> > problems. It "works" with Gentoo distcc. Rather than erroring |
19 |
> > out, it sends the work back to my Atom netbook, and says "Sorry, |
20 |
> > you have to do this yourself". This defeats the point of distcc. |
21 |
> > Outside of Gentoo distcc, the errors stop the build. So yes, I do |
22 |
> > need a 32-bit environment. |
23 |
> > |
24 |
> > I ran into this, trying to manually build Pale Moon (a Firefox |
25 |
> > fork) for my Atom netbook from a 64-bit environment. It doesn't |
26 |
> > work. Mozilla and its derivatives all use the same weird build |
27 |
> > scripts. See... |
28 |
> > https://forum.palemoon.org/viewtopic.php?f=37&t=10002 |
29 |
> > |
30 |
> > I eventually re-installed 32-bit Gentoo on my ancient Core2 |
31 |
> > machine. Since it only has 3 gigs of RAM, it's not losing anything. |
32 |
> > It successfully built the Atom-specific branch (a bunch of |
33 |
> > "web-developer" stuff removed) for my netbook. My netbook is |
34 |
> > actually "-march=bonnell" |
35 |
> > https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29 I |
36 |
> > selected that instead of the generic "-march=atom". |
37 |
> > |
38 |
> > By the way, Atom-specific-source Pale Moon builds are really snappy |
39 |
> > on a newer machine when built with "-march=native". On the other |
40 |
> > hand, the Firefox developers have utterly gone off the deep end. |
41 |
> > The Atrocious^H^H^H^H^H^H^H^H^H Australis GUI was the final straw |
42 |
> > that drove me away. |
43 |
> > |
44 |
> |
45 |
> |
46 |
> I think that you misunderstand how distcc works. The distcc process |
47 |
> *only* sends preprocessed data to the remote machine, and *only* gets |
48 |
> back object code. All preprocessing (headers) and linking (libraries, |
49 |
> combining *.o files) is *always* done on the host that the packages |
50 |
> will be used on, because slightly different versions would otherwise |
51 |
> cause problems. So your problem with "arch-specific headers and |
52 |
> libraries" *always* causes that part to run on the netbook, even if |
53 |
> the remote distcc server is exactly the same arch, etc. |
54 |
|
55 |
When you use distcc pump mode then also the preprocessing is done by |
56 |
the remote servers. This will cause problems when the include files on |
57 |
client and servers are not identical. |
58 |
|
59 |
-- |
60 |
Regards |
61 |
wabe |