[Xcb] Opensuse 11.2 missing xcb_xlib_lock

[Josh Triplett]

On Wed, Apr 14, 2010 at 01:36:30PM +0100, Hearns, John wrote:
> > libxcb-xlib.so.0 does not exist anymore.  Current XCB does not build
> or
> > ship it, and xcb_xlib_lock no longer exists.  If an application (or
> > more
> > likely some library that application links to) still uses that symbol
> > or
> > library, the application or library needs rebuilding against current
> > Xlib and XCB.
> > 
> > Note that due to the insanity of some build tools, sometimes
> > applications end up linking against libraries that they don't actually
> > need but their dependencies do, such as libxcb-xlib.
> > "objdump -p /path/to/application | grep NEEDED" will show you the
> exact
> > list of libraries the application links against.  If libxcb-xlib
> > appears
> > in that list, the application needs rebuilding; otherwise one of its
> > dependencies does.
> 
> 
> This is a really, really dumb policy.
> So you make an upgrade from one minor number release to another and a
> vital xorg library drops a routine,
> leaving applications which were working now broken?
> Deprecate a routine by all means.
> 
> And what if this application is a commercial application? You might not
> have the luxury of recompiling.

libxcb-xlib existed solely for the use of Xlib (libX11), and it said as
much.  No other application or library should *ever* have touched
libxcb-xlib or used xcb_xlib_lock.  libX11.so.6 previously linked to
libxcb-xlib.so.0, and used xcb_xlib_lock.  We fixed Xlib/XCB so that it
used a more robust mechanism to cooperate (socket handoff), and no
longer needed xcb_xlib_lock or libxcb-xlib.so.0.

Note that this issue only applied to libxcb-xlib, an internal library
for use by Xlib and Xlib alone.  We very carefully maintain the
stability of libxcb's API and ABI.  However, in the case of libxcb-xlib,
we fixed the one and only legitimate caller of it (Xlib) to not need it
anymore.

It looks to me, judging by the descriptions in your original mail, that
openSUSE might have actually shipped an empty libxcb-xlib.so.0 for
compatibility reasons.  That would avoid breaking any application or
library that for some reason linked to libxcb-xlib.so.0 directly (again
likely due to broken build processes), as long as the application or
library did not actually attempt to call xcb_xlib_lock.  However, since
you said that the application fails and says it wants that symbol, it
sounds like something actually tried to use that symbol.

To track down exactly what wanted that symbol, you can use "nm -D" on
any particular application or library to show both the symbols it
defines and the undefined symbols it expects other libraries to define.
I would suggest in particular that you check the following:

nm -D /usr/lib/libX11.so.6 | grep xcb_take_socket
nm -D /usr/lib/libX11.so.6 | grep xcb_xlib_lock

Exactly one of those should produce output, namely a line like this:

                 U xcb_take_socket

That result indicates an up-to-date Xlib using socket handoff; if you see
xcb_xlib_lock instead, then you have an outdated Xlib that uses a
suboptimal handoff mechanism.

I'd also suggest checking "nm -D /usr/lib/libxcb-xlib.so.0".  That
should show that the library does not define any interesting symbols,
and in particular that it does not contain xcb_xlib_lock.  That would
suggest an empty compatibility library, as I suggested above.

Note that if you have a libX11.so.6 that wants xcb_xlib_lock, and a
libxcb-xlib.so.0 that does not provide one, you have a very broken
system; the package dependencies on openSUSE's Xlib packages should
prevent that situation from arising.

So, if as expected you have an Xlib that wants xcb_take_socket and an
empty libxcb-xlib.so.0, then you need to track down what library or
application does try to use xcb_xlib_lock.  For that, you can use:

nm -D /path/to/application | grep xcb_xlib_lock

to find out if the application tried to use that symbol directly.  You
can also use "ldd /path/to/application" to find out the full list of
libraries the application pulls in, and check likely culprits the same
way.