编译在g ++ 4.7.1中遇到虚拟内存限制？

Question

我正在编译一些使用模板的代码（它基于boost :: msm框架）。当使用g ++ 4.7.1编译时，cc1plus进程达到大约2.4 Gb的RAM大小，并且因“虚拟内存耗尽：无法分配内存”错误而失败。

我使用的是32位编译器（切换到64位不是ATM的选项），机器本身是一个带有16Gb RAM的64位Ubuntu，编译是在64位的Debian chroot下执行的喘息的分布。在编译时，有足够的RAM可用，因此如果由于缺少物理上可用的RAM而导致编译失败，则首先达到4Gb。我尝试使用“ulimit -m”选项，设置为不同的值并将其设置为较小的大小会导致编译器提前失败，但当保留为“无限制”时，它会在上面提到2 + Gb时失败。

所以我猜其他一些东西一定限制了我。也许有人遇到了类似的问题并知道改变限制的方法吗？

Answer 1

在32位应用程序（包括编译器）中，通常可以获得2到3GB之间的虚拟空间中的用户模式。这是由保留的内存空间，内存空间碎片（可用虚拟内存，只是没有足够大的块来容纳new或malloc请求的任何大小的块）引起的，以及“内存预留”，其中进程分配了相当大的内存块，但实际上并没有全部使用它，所以它不会“填充”。

使用-M32无法使用64位GCC生成32位代码的任何特殊原因？那将是我的解决方案。