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
