Solution to permanent office installation under Fedora8

After installing some java software in Linux, we often find that "xcb_xlib.c: 50: xcb_xlib_unlock: Assertion 'C-& gt; xlib. lockfailed. "similar errors include the recent SUSE10.x, Fedora8, and Ubuntu7.x systems. Online articles are posted everywhere. Two ideas are put forward: 1. Go back to libx11 of FC7, when you detach the following two packages, you may not be able to detach them due to dependency issues. Add --

After installing some java software in Linux, we often find that "xcb_xlib.c: 50: xcb_xlib_unlock: Assertion 'C-> xlib. lock failed. "similar errors include the recent SUSE10.x, Fedora8, and Ubuntu7.x systems. Online articles are posted everywhere and a total of two ideas are raised:

1. Go back to libx11 of FC7,

When you uninstall the following two packages, you may not be able to uninstall the package due to dependency issues. Add the -- nodeps parameter to the backend to force uninstall the package. Take Fedora 8 as an example to unmount the package:

LibX11-1.1.3-4.fc8.i386.rpm

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

Uninstall.

Install the following two rpm packages and download them from the rpm serch website.

LibX11-1.0.3-8.fc7.i386.rpm

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

2. Modify the java program code by yourself. The main reason is:

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.

The description found above from Linuxfromscratch.org turns out that the xlib interface has been switched to the xcb library, while the cool people who designed xcb have to add an assertion to the 50th line of a source file, once upon a time, the program "not designed as standard" cannot run ...... I just didn't expect that the swing library of java is one of them ......

Solution: comment out the assert in the libxcb source code and re-compile and install it. Alternatively, add the-DNDEBUG option to gcc during compilation. Note that if the source code is used for installation, the previously installed version will be damaged (the restoration cannot be deleted )...... So if you are a software package, like me, and you don't want to make yourself unable to remember where the software is polluting your running environment ...... Or you can use a 64-bit system, but you have to run a 32-bit program ...... We recommend that you wait for the new version of the "standard-based design" program to come out.

3. The above method is collected on the Internet. In fact, the latest libcx package was available in the yum library's latest development. The following uses Fedora 8 as an example:

Yum -- enablerepo = development update libxcb

Export LIBXCB_ALLOW_SLOPPY_LOCK = 1

This solves the problem,

[Root @ localhost ~] # Rpm-qa | grep libxcb

Libxcb-1.1-1.fc9

Libxcb-devel-1.1-1.fc9

Haha, I found that Fedora 9 is also coming out.