在Linux下安裝一些java軟件，經常發現“xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock failed.”類似錯誤，包括最近的SUSE10.x、Fedora8以及Ubuntu7.x系統，網上文章到處貼，一共提出了兩種觀點：

1，倒退回FC7的libx11，

卸載以下兩個包的時候，可能有依賴問題無法卸載，在后面添加 --nodeps 參數強制卸載，以Fedora 8為例，將其里面的包：

libX11-1.1.3-4.fc8.i386.rpm

libX11-devel-1.1.3-4.fc8.i386.rpm

卸載。

安裝以下兩個rpm包，到rpm serch網站下載這兩個rpm包。

libX11-1.0.3-8.fc7.i386.rpm

libX11-devel-1.0.3-8.fc7.i386.rpm

2，自己修改java程序代碼，其主要原因是：

The libxcb package provides an interface to the X Window System protocol, which replaces the current Xlib interface. Xlib can also use XCB as a transport layer, allowing software to make requests and receive responses with both.

從Linuxfromscratch.org上面找到的說明，竟然是xlib的界面換到xcb庫里了，而設計xcb的牛人們又嚴格得緊，非要在某個源文件的第50行加一個assertion，弄得從前“不按標準設計”的程序都運行不了啦……我只是沒想到java的swing庫也是其中之一……

解決方法嘛，直接在libxcb的源碼里把那個assert注釋掉然后重新編譯再安裝就行了，又或者在編譯的時候給gcc加個-DNDEBUG選項。注意如果用源碼安裝的話是會損害之前安裝的版本的（無法通過刪除復原）……所以，如果你像我一樣是軟件包主義者，不希望讓自己都沒辦法記得放在哪的軟件污染你的運行環境的話……又或者在用一個64位的系統，但是又要運行32位程序的話……建議等“按標準設計”的新版程序出來再說。

3，以上是網上搜集的辦法，其實早在yum庫的最新development中就有了更新的libcx包，仍然以Fedora 8為例：

yum --enablerepo=development update libxcb

export LIBXCB_ALLOW_SLOPPY_LOCK=1

這樣就解決問題了，

[root@localhost ~]# rpm -qa|grep libxcb

libxcb-1.1-1.fc9

libxcb-devel-1.1-1.fc9

呵呵，發現Fedora 9也出來了。