Jonathan Callen <jcal...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 01/02/2016 01:27 PM, waltd...@waltdnes.org wrote:
> > On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote
> >
> >> 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.
> >
> > -m32 in a 64-environment works for "Hello World". More complex
> > code that requires arch-specific headers and libs will have
> > problems. It "works" with Gentoo distcc. Rather than erroring
> > out, it sends the work back to my Atom netbook, and says "Sorry,
> > you have to do this yourself". This defeats the point of distcc.
> > Outside of Gentoo distcc, the errors stop the build. So yes, I do
> > need a 32-bit environment.
> >
> > I ran into this, trying to manually build Pale Moon (a Firefox
> > fork) for my Atom netbook from a 64-bit environment. It doesn't
> > work. Mozilla and its derivatives all use the same weird build
> > scripts. See...
> > https://forum.palemoon.org/viewtopic.php?f=37&t=10002
> >
> > I eventually re-installed 32-bit Gentoo on my ancient Core2
> > machine. Since it only has 3 gigs of RAM, it's not losing anything.
> > It successfully built the Atom-specific branch (a bunch of
> > "web-developer" stuff removed) for my netbook. My netbook is
> > actually "-march=bonnell"
> > https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29 I
> > selected that instead of the generic "-march=atom".
> >
> > By the way, Atom-specific-source Pale Moon builds are really snappy
> > on a newer machine when built with "-march=native". On the other
> > hand, the Firefox developers have utterly gone off the deep end.
> > The Atrocious^H^H^H^H^H^H^H^H^H Australis GUI was the final straw
> > that drove me away.
> >
>
>
> I think that you misunderstand how distcc works. The distcc process
> *only* sends preprocessed data to the remote machine, and *only* gets
> back object code. All preprocessing (headers) and linking (libraries,
> combining *.o files) is *always* done on the host that the packages
> will be used on, because slightly different versions would otherwise
> cause problems. So your problem with "arch-specific headers and
> libraries" *always* causes that part to run on the netbook, even if
> the remote distcc server is exactly the same arch, etc.
When you use distcc pump mode then also the preprocessing is done by
the remote servers. This will cause problems when the include files on
client and servers are not identical.
--
Regards
wabe
