我已经在Debian下从源代码成功构建了TensorFlow，但目前无法使用Ubuntu 14.04 LTS从新的虚拟机开始构建。 Debian的IIRC我尝试了g ++ / gcc 5.2，但不得不降级到g ++ / gcc 4.9并且它有效。按照说明Installing from sources，如果我安装g ++，则版本为4.8且失败。
gcc：内部编译器错误：已杀死（程序cc1plus）
我还没有累4.9。
我检查了上一个Jenkins build的信息，但找不到工具及其版本列出的任何内容。即使是已解决的问题：Build tools and versions listed in Jenkins build log
g ++ / gcc的哪些版本可以使用？
构建机器使用什么版本的g ++ / gcc？
编辑
答案 0 :(得分：1)
问题不在于g ++ / gcc版本，而在于Bazel用于构建TensorFlow的CPU核心数量。
在VMware Workstation 7.1上运行多个构建时，全新安装的Ubuntu 14.04 LTS具有一个CPU核心，2G内存，2G交换分区和2G交换文件，构建运行速度最快。这可能不是最好的设置，但是到目前为止我发现的最好的设置始终如一。如果我通过VMware允许4个内核并使用Bazel构建它就会失败。如果我使用
使用Bazel选项--local_resources限制资源--local_resources 2048,2.0,1.0
成功构建
INFO: Elapsed time: 11683.908s, Critical Path: 11459.26s
--local_resources 4096,2.0,1.0
成功构建
INFO: Elapsed time: 39765.257s, Critical Path: 39578.52s
--local_resources 4096,1.0,1.0
成功构建
INFO: Elapsed time: 6562.744s, Critical Path: 6443.80s
--local_resources 6144,1.0,1.0
成功构建
INFO: Elapsed time: 2810.509s, Critical Path: 2654.90s
总之，更多的内存和更少的CPU内核最适合我的环境。
TLDR;
在构建过程中保持关注的同时，我注意到某些源文件需要很长时间才能编译，并且在构建时似乎会降低流速。就好像他们正在与其他源文件竞争资源，并且Bazel不知道这个关键资源，所以它允许竞争文件同时编译。因此，与未知资源竞争的文件越多，构建越慢。