Comment 24 for bug 86103

After further discussion with other colleagues, we determined that this problem really does not lie in Xlib/XCB. As far as we can tell, the JDK statically links with a libXinerama built against Xlib without XTHREADS #defined. This makes LockDisplay() compile to nothing. (The test case given in this bug simulates the same setup.) However, the JDK dynamically links to the system Xlib, which normally does have XTHREADS on any modern system. This never represented a supported configuration, even well before XCB; you cannot use an extension library that doesn't use XTHREADS with an Xlib that does use XTHREADS. XCB just exposes the problem, because an XCB-based Xlib always uses XTHREADS, and it needs the LockDisplay and UnlockDisplay macros to call the locking hooks because it does additional XCB-related processing in those hooks; thus, it includes locking correctness assertions in lieu of failing mysteriously when a library fails to do proper locking.

I spoke with Tom Marble of Sun about this at OSCON, and he and I both agreed that this bug lies with the JDK; it needs to either dynamically link to the system libXinerama, or statically link a libXinerama that uses XTHREADS (to *hopefully* match the system Xlib it dynamically links), or statically link an Xlib without XTHREADS. Xlib and extension libraries like libXinerama must agree about XTHREADS.

Thus, resolving as NOTOURBUG. I will post the same thing to the Sun bug, and Tom Marble assured me he would look into getting this fixed in the JDK.