編譯MySQL時Linux thread not found問題與解決
在FC6系統中從源碼安裝MySQL時遇到問題如下,提示Linux thread not found的錯誤，代碼如下：
- #./configure --prefix=/usr/local/mysql
- …
- …
- checking "LinuxThreads"... "Not found"
- configure: error: This is a linux system and Linuxthreads was not found. On linux Linuxthreads should be used.
- Please install Linuxthreads (or a new glibc) and try again.
- See the Installation chapter in the Reference Manual for more information.
在網上隨便搜一下關鍵字“Linuxthreads was not found”可以找到很多相關的帖子，但大多都沒有提供完整解決方案。
下面來分析一下上面的出錯情況，并就此提供一個解決方案。從上面的出錯可以很明顯的看出是說系統缺少線程庫。沒有線程，Linux可以運行嗎？呵呵，那當然不行。既然沒有linuxthread那現在用的是什么呢？
答案是NPTL。
作為去除過時的LinuxThreads 庫的一個步驟，在 Fedora Core 5 test1 中編譯和連接的代碼現在自動使用NPTL頭文件和庫。在過去的版本中，從 Red Hat Linux 9 開始，默認的線程模型是LnuxThreads，因為接口是最通用的。NPTL 接口的優點在于，線程取消的處理更快 (使用 -fexception 參數時，即使在 C 代碼中)。現在附加的接口也已可用，不需要特殊的編譯器和連接器參數。
下面言歸正轉，怎樣解決？
可以修改程序去支持NPTL，也可以在編譯時加上對原有thread庫的支持。我選擇了后者，這樣可以不動MySql的源代碼。在mysql手冊中搜關鍵字thread,可以查到在Chapter 2. Installing and Upgrading MySQL。
2.8.5. MIT-pthreads Notes
- If your system does not provide native thread support, you should build MySQL using the MIT-pthreads package.
- This includes older FreeBSD systems, SunOS 4.x, Solaris 2.4 and earlier, and some others. See Section 2.1.1, “Operating Systems Supported by MySQL”.
- Beginning with MySQL 4.0.2, MIT-pthreads is no longer part of the source distribution.
- If you require this package, you need to download it separately from http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz
- After downloading, extract this source archive into the top level of the MySQL source directory.
- It creates a new subdirectory named mit-pthreads.
從上可以看出：只要下到mit-thread源碼就可以了。但不知道為什么官方網站上已經沒有下了的了(我又找了一個官網的鏡像還是沒有，郁悶ing)。再仔細看一下上面，只是將線程源碼放到MySql源碼目錄的根目錄下以mit-pthreads命名的目錄。官方沒有自己去下一個也是一樣的，只要解壓后放到上述位置就可了。
于是去下了一個pthread源碼包，解壓放到相應位置。
再執行：
- #./configure --prefix=/usr/local/mysql --with-mit-threads
就順利通過了。
附：NPTL與 LinuxThreads 相比的優點
NPTL 沒有使用管理線程。管理線程的一些需求，例如向作為進程一部分的所有線程發送終止信號，是并不需要的；因為內核本身就可以實現這些功能。內核還會處理每個線程堆棧所使用的內存的回收工作。它甚至還通過在清除父線程之前進行等待，從而實現對所有線程結束的管理，這樣可以避免僵尸進程的問題。由于 NPTL 沒有使用管理線程，因此其線程模型在 NUMA 和 SMP 系統上具有更好的可伸縮性和同步機制。
使用 NPTL 線程庫與新內核實現，就可以避免使用信號來對線程進行同步了。為了這個目的，NPTL 引入了一種名為 futex 的新機制。futex 在共享內存區域上進行工作，因此可以在進程之間進行共享，這樣就可以提供進程間 POSIX 同步機制。我們也可以在進程之間共享一個 futex。這種行為使得進程間同步成為可能。實際上，NPTL 包含了一個 PTHREAD_PROCESS_SHARED 宏，使得開發人員可以讓用戶級進程在不同進程的線程之間共享互斥鎖。
由于 NPTL 是 POSIX 兼容的，因此它對信號的處理是按照每進程的原則進行的；getpid() 會為所有的線程返回相同的進程 ID。例如，如果發送了 SIGSTOP 信號，那么整個進程都會停止；使用 LinuxThreads，只有接收到這個信號的線程才會停止。這樣可以在基于 NPTL 的應用程序上更好地利用調試器，例如 GDB。
由于在 NPTL 中所有線程都具有一個父進程，因此對父進程匯報的資源使用情況（例如 CPU 和內存百分比）都是對整個進程進行統計的，而不是對一個線程進行統計的。
NPTL 線程庫所引入的一個實現特性是對 ABI（應用程序二進制接口）的支持。這幫助實現了與 LinuxThreads 的向后兼容性。
【編輯推薦】
