| 1 |
On Saturday, May 02, 2015 9:10:01 PM Walter Dnes wrote: |
| 2 |
> I ran into a couple of problems with distcc cross-compiling on a |
| 3 |
> 64-bit host for a 32-bit host. One was with ffmpeg, and the other |
| 4 |
> one was seamonkey (built-from-source). There's a thread at |
| 5 |
> http://www.gossamer-threads.com/lists/gentoo/user/298324 which mentions |
| 6 |
> ffmpeg with symptoms identical to mine. |
| 7 |
> |
| 8 |
> ffmpeg is no problem doing locally. But seamonkey built-from-source |
| 9 |
> is a 14 hour marathon on the ancient 32-bit Atom. It's the reason I got |
| 10 |
> into distcc in the first place. Fortunately, seamonkey-bin exists, and |
| 11 |
> builds properly. Basic Youtube videos (End Of The Line; Travelling |
| 12 |
> Wilburys; HTML5; H264; 360-line-resolution) peg the double-core Atom |
| 13 |
> with a cpu load of 2.75. That's not Seamonkey's fault; what do you |
| 14 |
> expect from an Atom, driving an un-accelerated framebuffer? I'm happy |
| 15 |
> that the devs went to the trouble of reverse-engineering the Poulsbo |
| 16 |
> (bleagh) chip. |
| 17 |
> |
| 18 |
> The thread listed above mentions that distcc without "pump" can |
| 19 |
> sometimes solve crossdev build problems. Can it be used to build |
| 20 |
> seamonkey from source on the host and manually push it to the client? |
| 21 |
> |
| 22 |
> While we're on the topic of distcc, it's update time. The client |
| 23 |
> shows... |
| 24 |
> |
| 25 |
> aa1 ~ # gcc-config -l |
| 26 |
> [1] i686-pc-linux-gnu-4.8.4 * |
| 27 |
> |
| 28 |
> ...and the host shows... |
| 29 |
> |
| 30 |
> [d531][waltdnes][~] gcc-config -l |
| 31 |
> [1] i686-pc-linux-gnu-4.8.3 * |
| 32 |
> |
| 33 |
> [2] x86_64-pc-linux-gnu-4.8.4 * |
| 34 |
> |
| 35 |
> According to the crossdev "--help" listing... |
| 36 |
> -S, --stable Use latest stable versions as default |
| 37 |
> -C, --clean target Uninstall specified target |
| 38 |
> |
| 39 |
> This implies that on the host, I should do the following... |
| 40 |
> |
| 41 |
> crossdev -C -t i686-pc-linux-gnu |
| 42 |
> crossdev -S -t i686-pc-linux-gnu |
| 43 |
> |
| 44 |
> Before I take the plunge, can anybody with experience confirm that |
| 45 |
> this is the correct way to do it? |
| 46 |
> |
| 47 |
> |
| 48 |
|
| 49 |
The difference is that without pump mode the source files are run through the |
| 50 |
preprocessor locally and a single preprocessed file is sent to the host for |
| 51 |
each compilation unit. With pump mode the actual source is sent to the host |
| 52 |
and it request the headers from the client as needed and the host caches them |
| 53 |
so they're only sent once. So pump mode uses less network traffic but it's not |
| 54 |
necessarily faster, in fact it's much slower in some cases. |
| 55 |
|
| 56 |
Some packages do custom preprocessing and other weird things during the build |
| 57 |
process that cause problems with pump mode since it caches copies of the |
| 58 |
unmodified headers. If you're lucky it just fails (and usually falls back on |
| 59 |
compiling locally), if you're not then it may succeed and you'll get runtime |
| 60 |
bugs. I haven't find a package yet that fails without pump mode as long as your |
| 61 |
CFLAGS are set properly. |
| 62 |
|
| 63 |
As for updating, you likely don't need to. According to the distcc FAQ the |
| 64 |
minor version number is not as important. If you still want to, I *think* you |
| 65 |
can just mask the other versions using an atom like cross-i686-pc-mingw32/gcc |
| 66 |
to ensure that you get the version you want but I'm not sure about this and |
| 67 |
there may be a better way. |
| 68 |
|
| 69 |
-- |
| 70 |
Fernando Rodriguez |
Archives