在清華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了，何必如此麻煩呢？
