It would then iterate over this process, depending on how many objects there are to link.
Once it's down to a few "combined OBJ" files on the building machine, it then links them together.
Lots of questions in the above, which would likely lead to configuration variables:
1. Do we even have a tool that will "partial link"?
2. How many OBJs to send out to be linked together for best performance?
3. How many "combined OBJs" are enough to link locally for best performance?
4. It would want to be "smart" about combinations. Perhaps instead of combining all the OBJs, it instead sends out requests to combine each OBJ with all the LIBs, generating a "combined OBJ" which likely has most of its external references satisfied (so the only heavy lifting the local machine would have to do is put together any external references from one of these returned "combined OBJs" to another).
There may be other parts I'm not considering, but that's the benefit of "many eyes," right? ;-)
Sincerely,
Ken Beal
On 1/9/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
On 1/9/06, Victor Norman <[EMAIL PROTECTED]> wrote:
> I'm very interested in investigating the idea of speeding up the linking
> stage. Does anyone know of anyone doing work on this process? Is
> distributed and/or parallel linking even possible?
I'm not sure, but I do think there are bottlenecks in the
linker that haven't really been explored yet. Every
now and then somebody finds and fixes one, e.g.
http://sourceware.org/ml/binutils/2003-09/msg00112.html
So a sufficiently motivated developer might be able
to speed up linking for her app by improving binutils' ld
(and then posting the patches on the binutils mailing list
for review).
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
