Gentoo版Linux操作系统的前世今生 （5）

Enoch的第一块绊脚石

不可避免的一天，Enoch碰到了它的第一块绊脚石。在加入了Xfree86、glib、gtk＋之后，我决定把xmms（一个基于 X11/gtk＋的MP3/CD播放软件）弄进我的发行版，因为也该到了用音乐来调剂调剂的时候了！但是在安装好xmms之后启动它时......X死锁了！最初我觉得是自己使用的编译器的优化参数造成的（"-O6 -mpentiumpro"，在你看来有点诧异吧？）。第一个想到的解决办法就是用标准的编译器选项来编译，但是问题依然没有解决。然后只好到处寻找解决方法，接下来整整几个星期的开发时间我都用来追踪这个错误。一天，我收到了一个叫Omegardan的Enoch使用者的电子邮件，他也同样碰到了 xmms的这个死锁问题。

交流了一段时间然后历经了n个小时的检测后我们发现死锁的原因在于POSIX的线程描述符（POSIX threads-related issue）。因为一些原因，pthread_mutex_trylock()函数没有返回它应该返回的值。作为一个Linux版本的创始者，这种类型的 bug是我真的不愿意碰见的家伙。我指望开发人员能能够释出完美的源代码以便我可以把精力放到提高Linux易用性上，而不是把时间花在修复别人源代码的 bug上。当然很快我就发现这种希望仅仅只是一个美好的想法罢了，相同的错误有时还是会出现。

在找到问题后，我们发现它不是xmms本身的问题，也不时gtk＋或glib的问题，也不是Xfree86 3.3.5没有thread-safe和死锁的问题，而是令人惊异的存在于Linux 的POSIX的线程执行本身，具体来说就是版本2.1.2的GNU C库（glibc）的部分代码中存在bug。我很震惊的是在Linux如此核心的部分居然存在这样严重的bug（而且我们为Enoch使用的glibc的版本是它的release版本，并不是什么prerelease版本或是CVS版本！）。

那么怎么样才能解决这个问题呢？我们不可能马上就能拿出一个修补方案，但是在浏览了一堆glibc开发人员的邮件列表后，我偶然发现了还有一个人也碰到了相同的问题，然后在glibc开发人员在回复他的邮件里我们找到了那个附带的补丁，它为我们解决了那个线程问题。但我令我好奇的是为什么同样使用 glibc 2.1.2的RedHat 6没有受这个bug的影响（当时RedHat 6的发布时间先于那个补丁的出现）。为了找到答案，我下载了RedHat里glibc的SRPM包（source RPM）想看一下他们使用的补丁是怎么样的。

RedHat有他们自己的glibc补丁来解决pthread_mutex_trylock()函数的问题。显而易见的是他们也碰到了同样的问题，然后自己进行了修补。但是由于RedHat没有把这个补丁回馈到glibc的开发社区，其他人们就没有办法分享这个补丁。但是也可能是RedHat把这个修补方案回馈到了glibc的开发社区，然儿glibc的开发人员并没有接受这个修补方案。或者这个bug只会在特定版本的binutils和特定版本的编译器连用时才会触发，然而RedHat使用的binutils和编译器的版本并不是这两个特定的版本（虽然RedHat还是给出了这个补丁）。我猜测我们永远也不会知道究竟事情的真相是什么样的，但是我学会的一件事情是：RedHat的 SRPM包里有很多定制的补丁和增强代码，而这些代码和补丁看来从来没有回馈到原始的开发人员那里。我将会为此来上一段激昂的演说。

激情的演说

当你将一大堆各种各样的源代码汇聚成一个Linux发行版时，把所有你做好的bug fix和补丁反馈给原始的某个软件包的开发人员是一件相当重要的事情，就如我了解到的那样，这是发行版的开发人员为Linux做贡献的很多途径中的一个。我们也恰好就是这样的一群人，为的就是把很多不同的程序和软件集合在一起，让它们工作起来就像是一个整体。将来我们也会把我们们对一些软件所做的修改和补丁反馈回原始软件的开发人员以便其他的用户和后来的发行版能从中受益。如果你只是把补丁留在你自己那里，这样做不会对任何人有什么帮助，很多人们将会为一些相同的问题浪费掉大量的时间。这种不顾别人的方式违背了整个开源世界的精神和宗旨，同时对Linux的发展也只是有害无益。或许我应该说这样的做法对我们来说就是一个大大的“BUG”。

不幸的是一些发行版（啊咳）（RedHat）并不如其他一些版本（Debian）那样对整个开源社区分享他们的成果。