Re: [gentoo-user] Difference between "normal distcc" and "distcc with pump"?

[Fernando Rodriguez <frodriguez.developer@outlook.com>]

On Saturday, May 02, 2015 9:10:01 PM Walter Dnes wrote:
>   I ran into a couple of problems with distcc cross-compiling on a
> 64-bit host for a 32-bit host.  One was with ffmpeg, and the other
> one was seamonkey (built-from-source).  There's a thread at
> http://www.gossamer-threads.com/lists/gentoo/user/298324 which mentions
> ffmpeg with symptoms identical to mine.
> 
>   ffmpeg is no problem doing locally.  But seamonkey built-from-source
> is a 14 hour marathon on the ancient 32-bit Atom.  It's the reason I got
> into distcc in the first place.  Fortunately, seamonkey-bin exists, and
> builds properly.  Basic Youtube videos (End Of The Line; Travelling
> Wilburys; HTML5; H264; 360-line-resolution) peg the double-core Atom
> with a cpu load of 2.75.  That's not Seamonkey's fault; what do you
> expect from an Atom, driving an un-accelerated framebuffer?  I'm happy
> that the devs went to the trouble of reverse-engineering the Poulsbo
> (bleagh) chip.
> 
>   The thread listed above mentions that distcc without "pump" can
> sometimes solve crossdev build problems.  Can it be used to build
> seamonkey from source on the host and manually push it to the client?
> 
>   While we're on the topic of distcc, it's update time.  The client
> shows...
> 
> aa1 ~ # gcc-config -l
>  [1] i686-pc-linux-gnu-4.8.4 *
> 
> ...and the host shows...
> 
> [d531][waltdnes][~] gcc-config -l
>  [1] i686-pc-linux-gnu-4.8.3 *
> 
>  [2] x86_64-pc-linux-gnu-4.8.4 *
> 
> According to the crossdev "--help" listing...
>     -S, --stable             Use latest stable versions as default
>     -C, --clean target       Uninstall specified target
> 
>   This implies that on the host, I should do the following...
> 
> crossdev -C -t i686-pc-linux-gnu
> crossdev -S -t i686-pc-linux-gnu
> 
>   Before I take the plunge, can anybody with experience confirm that
> this is the correct way to do it?
> 
> 

The difference is that without pump mode the source files are run through the 
preprocessor locally and a single preprocessed file is sent to the host for 
each compilation unit. With pump mode the actual source is sent to the host 
and it request the headers from the client as needed and the host caches them 
so they're only sent once. So pump mode uses less network traffic but it's not 
necessarily  faster, in fact it's much slower in some cases.

Some packages do custom preprocessing and other weird things during the build 
process that cause problems with pump mode since it caches copies of the 
unmodified headers. If you're lucky it just fails (and usually falls back on 
compiling locally), if you're not then it may succeed and you'll get runtime 
bugs. I haven't find a package yet that fails without pump mode as long as your 
CFLAGS are set properly.

As for updating, you likely don't need to. According to the distcc FAQ the 
minor version number is not as important. If you still want to, I *think* you 
can just mask the other versions using an atom like cross-i686-pc-mingw32/gcc 
to ensure that you get the version you want but I'm not sure about this and 
there may be a better way.

-- 
Fernando Rodriguez