在清华BBS上看到有些朋友在 FreeBSD 4.0 Release上编译MySQL时通不过，停留在编译

　　sql/sql_yacc.cc文件处，很长时间都通不过，有网友说编译了三个多小时都通不过， 我真

　　的很佩服他的耐心了。我也遇到了同样的问题，还有过错误的判断。 通过与清华BBS的网友

　　交流，我相信找到了问题所在。

　　有网友说用ports安装就没有什么问题，但并没有进一步说明到底是因为什么。 看了一

　　下ports中对mysql-server的说明，原来用ports编译mysql需要一个包：libtool-1.3.3。

　　请看FreeBSD对libtool这个包的描述：

　　This is GNU Libtool, a generic library support script. Libtool hides the

　　complexity of using shared libraries behind a consistent, portable interface.

　　To use libtool, add the new generic library building commands to your

　　Makefile, Makefile.in, or Makefile.am.

　　这是GNU Libtool，通用的库支持脚本。Libtool用一致的方便的接口隐藏了使用共享库

　　的复杂性。

　　（蹩脚的翻译）要使用libtool，将新的通用库 编译命令加入Makefile，Makefile.in，

　　或Makefile。am中。

　　使用ports安装需要先安装libtool-1.3.3这个包，但是不用ports安装， 直接编译也需

　　要么？实验证明是不需要的，在没有安装libtool包的情况下直接编译mysql也可以通过，只

　　是停留在编译sql_yacc.cc这个文件的时间非常长， 一般人都会觉得编译出了问题而中断编

　　译过程。如果你耐心等待，并且有足够的内存和交换分区，应该是可以编译通过的。

　　如果在编译sql_yacc.cc的时候出现了下面的错误：

　　Internal Compiler error: program cc1plus got fatal signal 11或

　　Out of virtual memory或

　　virtual memory exhausted

　　该问题是gcc要求大量的内存编译带有嵌入函数(inline function)的sql_yacc.cc， 而

　　系统内存和交换分区不足，那么可以使用./configure --with-low-memory重新配置， 再进

　　行编译。

　　如果你正在使用gcc，该选项使得将-fno-inline加到编译行，如果你正在使用其他的编

　　译器，则加入-O0。即使你有特别多的存储器和交换空间，也应该试一试--with-low-memory

　　选项。

　　我通过测试表明，使用--with-low-memory显著的降低了编译时间，而用ports安装时，

　　ports中的patch将-O0加入了Makefile，不使用--with-low-memory也同样可以快速的编译完成。

　　其实，FreeBSD 4.0 Release的ISO安装盘中有mysql的二进制安装包， 不用编译，

　　pkg_add就ok了，何必如此麻烦呢？