Yes, I have tried both pump and regular mode, and both behave the same way.<br><br>A lot of the projects that I will be compiling include boost, and I believe that the pump fails on those, and falls back to regular mode. <br>
<br>-Jeff<br><br><div class="gmail_quote">On Tue, Jun 29, 2010 at 10:48 AM, Fergus Henderson <span dir="ltr"><<a href="mailto:fergus@google.com">fergus@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<p>Did you try using pump mode?<br>
That should give you a better build speed-up and may also avoid this issue.</p><div><div></div><div class="h5">
<p>On Jun 29, 2010 6:32 AM, "Jeff Kilpatrick" <<a href="mailto:kilpatrick.jeff@gmail.com" target="_blank">kilpatrick.jeff@gmail.com</a>> wrote:<br type="attribution">> Oops, my original response went directly to Ihar, rather than to the list.<br>
> <br>> ----<br>> <br>> <br>> <br>> Thank you for your response.<br>> <br>> We do have a tool internally that could 'scrub' the object file of its<br>> dynamic symbols, and could be adapted for this purpose. However, I'm<br>
> hesitant to modify anything with the .o and .so with an external tool, as in<br>> some cases, it may be hiding a legitimate issue. Once an exception makes it<br>> into the code, its tempting to continue adding exceptions to fix issues.<br>
> Before you know it, you have 600 branches with unique 'fixes' to them :)<br>> <br>> Once we get a consistent checksum on the .o and .so files, they'll be<br>> packaged into a .iso, which will also need to be repeatable. This can be<br>
> challenging as well, since attributes on the files can affect the final<br>> checksum.<br>> <br>> -Jeff<br>> <br>> <br>> On Tue, Jun 29, 2010 at 6:58 AM, Ihar `Philips` Filipau <<br>> <a href="mailto:thephilips@gmail.com" target="_blank">thephilips@gmail.com</a>> wrote:<br>
> <br>>> Hi Jeff!<br>>><br>>> You can try to collect the check-sum only for the ELF segments which are<br>>> actually derived from the the source code, omitting the segments with the<br>>> extra compiler's info. I do not know any ready tool for the purpose, but<br>
>> coding something like this - print on stdout all segments except the<br>>> black-listed - shouldn't be too complicated.<br>>><br>>><br>>> On Tue, Jun 29, 2010 at 11:41 AM, Jeff Kilpatrick <<br>
>> <a href="mailto:kilpatrick.jeff@gmail.com" target="_blank">kilpatrick.jeff@gmail.com</a>> wrote:<br>>><br>>>> Thank you for your response.<br>>>><br>>>> Yes, this is the only difference in the object file. We've taken great<br>
>>> pains over the last few years, removing anything that would cause checksums<br>>>> to mismatch.<br>>>><br>>>> I will do some research myself, and talk to a few developers to see if<br>
>>> they can help me.<br>>>><br>>>> Thanks<br>>>> -Jeff<br>>>><br>>>><br>>>> On Tue, Jun 29, 2010 at 1:32 AM, Martin Pool <<a href="mailto:mbp@sourcefrog.net" target="_blank">mbp@sourcefrog.net</a>> wrote:<br>
>>><br>>>>> On 29 June 2010 13:02, Jeff Kilpatrick <<a href="mailto:kilpatrick.jeff@gmail.com" target="_blank">kilpatrick.jeff@gmail.com</a>><br>>>>> wrote:<br>>>>> > Hello,<br>
>>>> ><br>
>>>> > At my work, we've just begun to investigate how much of an impact that<br>>>>> > distcc will have on our builds.<br>>>>> ><br>>>>> > We typically perform 200 builds a week, ranging from a thousand lines<br>
>>>> of<br>>>>> > code, up to 600,000 lines of code each. Our back end build scripts are<br>>>>> based<br>>>>> > on python, and use Linux make to build. We are running VMWare images on<br>
>>>> a<br>>>>> > blade cluster, and each of our three new build servers have 20Ghz<br>>>>> processing<br>>>>> > power, with 4G of RAM. Our primary build environments are loop back<br>
>>>> ISOs,<br>>>>> > from a central CIFS server, and are unioned together with unionfs. Our<br>>>>> > source code is then copied into this environment, and we proceed with<br>>>>> our<br>
>>>> > build, using chroot to enter our build environment. Our 'distcc'<br>>>>> machines<br>>>>> > use the same loop back system, with only our OS and distcc being<br>>>>> accessible.<br>
>>>><br>>>>> That's pretty cool.<br>>>>><br>>>>> > One of the most important things for our builds, due to the market that<br>>>>> we<br>>>>> > are in, is that our builds must be reproducible, with repeatable<br>
>>>> md5sums on<br>>>>> > our shared objects, based on the same label and same dependencies. In<br>>>>> our<br>>>>> > recent tests, we were able to take a particular build from 24 minutes<br>
>>>> to 14<br>>>>> > minutes, then finally 5 minutes, using distcc and adjusting our VMs.<br>>>>> > However, when performing an md5sum on our final shared objects / object<br>>>>> > files, the checksums change every build. We dropped down to just using<br>
>>>> g++<br>>>>> > to perform our linking, all locally, but our object files are still<br>>>>> > mismatching.<br>>>>> ><br>>>>> > In the object files' `objdump -s` output, it appears that an entry is<br>
>>>> being<br>>>>> > made into all our object files with the following syntax<br>>>>> "distccd_XXXXX",<br>>>>> > with XXXXX being a seemingly random combination of characters.<br>
>>>><br>>>>> Hi Jeff,<br>>>>><br>>>>> I think this is coming from gcc recording the input file name in the<br>>>>> object file. distccd_xxxx.ii is the temporary file name used on the<br>
>>>> server.<br>>>>><br>>>>> > In the same object file, compiled locally without distcc, we get a<br>>>>> rather<br>>>>> > generic <built-in> placeholder.<br>
>>>><br>>>>> I think this means it's coming from the builtin preprocessor.<br>>>>><br>>>>> I probably won't have time to work on this myself but if you have a<br>>>>> programmer interested in it there are two possible avenues:<br>
>>>><br>>>>> - make gcc read from a file called <built-in> in a temporary subdirectory<br>>>>><br>>>>> - find some way to stop it recording the compiler input file name<br>
>>>><br>>>>> Is that the only difference in the object files? It's pretty common<br>>>>> for compilers to also record something about the time the compilation<br>>>>> was run or for source files to build this in, which would mean they<br>
>>>> change every time.<br>>>>><br>>>>> ><br>>>>> > I've reviewed the source code for distcc, and seen a few references to<br>>>>> this<br>>>>> > distccd_xxxxx. Unfortunately, I'm not a programmer, and thus am at a<br>
>>>> loss on<br>>>>> > how to further troubleshoot this, or even if its possible to get<br>>>>> consistent<br>>>>> > checksums with distcc.<br>>>>> ><br>
>>>> ><br>>>>> > Versions<br>>>>> > =======<br>>>>> > g++ (Gentoo 4.3.2-r4 p1.8, pie-10.1.5) 4.3.2<br>>>>> ><br>>>>> > distcc 3.1 i686-pc-linux-gnu<br>
>>>> > (protocols 1, 2 and 3) (default port 3632)<br>>>>> > built Mar 29 2010 10:55:35<br>>>>> ><br>>>>> > Kernel: 2.6.9-89.ELsmp<br>>>>> ><br>
>>>> > Command being issued:<br>>>>> > DISTCC_VERBOSE=1 make -j24 CXX="distcc"<br>>>>> ><br>>>>> > Here's the partial output of objdump -s:<br>
>>>> > 04f0 00030000 5f6d6f76 655f636f 6e737472 ...._move_constr<br>>>>> > 0500 7563745f 66776b2e 68000300 00474454 uct_fwk.h....GDT<br>>>>> > 0510 79706573 2e68000a 00007365 72646566 ypes.h....serdef<br>
>>>> > 0520 732e6800 01000073 75666669 782e6870 s.h....suffix.hp<br>>>>> > 0530 70000b00 00646973 74636364 5f616333 p....distccd_ac3<br>>>>> > 0540 31633936 612e6969 000c0000 61646c5f 1c96a.ii....adl_<br>
>>>> > 0550 62617272 6965722e 68707000 0d000062 barrier.hpp....b<br>>>>> > 0560 6f6f6c5f 6677642e 68707000 0e000069 ool_fwd.hpp....i<br>>>>> > 0570 6e746567 72616c5f 635f7461 672e6870 ntegral_c_tag.hp<br>
>>>> > 0580 70000e00 00766f69 645f6677 642e6870 p....void_fwd.hp<br>>>>> ><br>>>>> > Thank you for reviewing my issue.<br>>>>> ><br>>>>> > -Jeff<br>
>>>> ><br>>>>> > __<br>>>>> > distcc mailing list <a href="http://distcc.samba.org/" target="_blank">http://distcc.samba.org/</a><br>>>>> > To unsubscribe or change options:<br>
>>>> > <a href="https://lists.samba.org/mailman/listinfo/distcc" target="_blank">https://lists.samba.org/mailman/listinfo/distcc</a><br>>>>> ><br>>>>><br>>>>><br>>>>><br>
>>>> --<br>
>>>> Martin<br>>>>><br>>>><br>>>><br>>>> __<br>>>> distcc mailing list <a href="http://distcc.samba.org/" target="_blank">http://distcc.samba.org/</a><br>
>>> To unsubscribe or change options:<br>
>>> <a href="https://lists.samba.org/mailman/listinfo/distcc" target="_blank">https://lists.samba.org/mailman/listinfo/distcc</a><br>>>><br>>><br>>><br>>><br>>> --<br>>> Don't walk behind me, I may not lead.<br>
>> Don't walk in front of me, I may not follow.<br>>> Just walk beside me and be my friend.<br>>> -- Albert Camus (attributed to)<br>>><br></p>
</div></div></blockquote></div><br>