编译MySql时Linux thread not found问题与解决
时间:2007-03-20 来源:williamyoung
今天碰到一师兄在FC6系统中从源码安装MySql时遇到问题:
#./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。
NPTL即native posix thread library与 LinuxThreads 相比,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 的向后兼容性。