-----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.
- --
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJWiFzXAAoJEEIQbvYRB3mgwZIP/1bb2cJ5d5DselrzYQd48wXJ
LnftAoBgUtYjc866EYPMYJchW+xQtrSJzuHEPuWDjiwIbgRA7zQzHCYRwJWNXrry
iZPVKaxnTumU/ttUZHZHiBtga5HULwAPkSwCBPrFpFYXuvghNuGIG4Kdz+8a18Ef
hFIbY/qRIXJgNq8bIekoOY7ED1/27mPcNW1BReJoCOo+oTPp6QqbE/nZ+rDtQPBi
Gx8jtJptaHtQ7kCN4ddDfgYQry0/yU5QaScLwzExDXAIAw3I14ecMMu8AtSpacPx
UZ5HOb/iuV4tUcB5yEhbasFAgs7i36Cr0WtcbFZ4XaUA6m92ldwiQrAMMRMT3Vxm
X5Hemtckw9feFxvJw5SEupLbWTG13LZ/pZK03o8DgJIVaEkZcis6RhBZZCwZzuDq
erX3xcsS+vHRrIrZKIbA7Fwc3ronbToH45EcXfdobMLlUp5wx1W2lB1WcS/a8WtJ
L5+c3GmKbjg6HAarZ3kWTHhr0X20J8SLkx2pwUYn7kX6bZEgHpIsyb6I+2ZHkfq4
K1Jc96WVfFwQSu77TPhURUcFMPXlv1zjKnTtwesgLvSVxKSq5wZu/295dkmqeuyg
of2w5wrWaq7DZCPkNVemtknVXeFgAUglkpr9M4DWG8DN4vTlN5naG8D3XPxprT3B
KJCTrSGYoRe/V6Fk/pJ/
=mMUw
-----END PGP SIGNATURE-----
