分布式/多进程编译不是问题，问题是link。

prolj

聊聊这个吧。

jzhang918

所以我们需要一个快的链接器。这也是gold的设计目标之一。

prolj

ld64设计的也不错。

bluesea666

学习了.
"问题是link"  不明白,能讲讲吗?

317316abcd

是不是与任务调度相关

xyfree

Link 要产生的东西，一般是只有一个，
而且同时依赖多个。。。东西（譬如o文件）
似乎是不能并行化的。

bluesea666

Link 要产生的东西，一般是只有一个，
而且同时依赖多个。。。东西（譬如o文件）
似乎是不能并行化的。
xyfree 发表于 2010-06-06 22:51

    学习了.

prolj

回复 2# jzhang918


    这个你有想法不？发paper归你，创意分享给我吧。

Cyberman.Wu

没做过编译系统，没太多概念，不过以前因为项目比较大用过分布式编译。

以前我几个同事做过一个基于Tornado中带的GCC2.95的一个分布式编译系统，实际上就是通过socket发送文件，多台机器并行编译，然后在同一台机上上进行链接，好像当时链接是没有想出办法来的。不过这个系统后来没怎么推起来，主要是各机器路径不同时如果用源代码调试会找不到文件。（其实最早我是想基于distcc来做一个的，后来发现Tornado中带的make不支持-j参数。）

在原来公司还用过一个基于VC6.0的分布式编译系统（名字忘了，是一个商业软件），那个做得蛮好的，不需要参与编译的系统安装VC6.0或必须完全相同的补丁，编译之后调试也没任何问题，不过链接过程感觉也是在一台机上完成的。它应该是对VC6.0分析的比较透彻，在各编译节点上生成一个“虚拟”的环境，但头文件问题如何处理的还不清楚。

其实编译相对很容易并行，例如我的4核工作站上简单地用-j 4编译，性能一下子就上去了，但链接好像比较麻烦，不知道能否生成一些小信息，再利用这些信息分配链接任务？或者某种分布式系统可以提高它？

system888net

这个话题有意义.