I think distcc is normally used by people who are doing their work on the fastest machine, and distributing the compiles to slower machines. Since the linking isn't done in parallel unless you're building multiple executables, there isn't much of a pay-off for distributed linking in that case.
The main ostacle I see with distributed linking is that libraries are often found using LD_LIBRARY_PATH and combinations of -L and -l so that the logic needed to correctly figure out which files to send or not send, and how to adjust the command-line parameters to ensure the right libraries are loaded, is somewhat daunting. These problems don't exist with C/C++ compiles because distcc preprocesses the source. On 3/23/06, Victor Norman <[EMAIL PROTECTED]> wrote: > Martin, et al., > > In one of our builds, there are a bunch of templated classes, templated > functions, etc., etc. The result is that the 'ld' part of building takes a > long time now, as ld instantiates the templates appropriately. As a result, > we'd like to be able to do distributed ld-ing, so that the fastest available > machine does the loading. I think this would be possible -- we could gather > up all the .o files on the build machine and send them over the wire to the > compilation machine, which could do the loading and linking, and send the > result back. > > Do you see any problems with this? Would it be easy, you think, to make > this happen? I think it would be mostly work in arg.c so make distcc > recognize gnu ld arguments, etc. > > Vic > > > > --------------------------------- > Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. > __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
