[Xcb] [PATCH:libX11] Don't need to link libX11-xcb against libX11

[Adam Jackson]

On Wed, 2013-11-20 at 16:23 -0800, Josh Triplett wrote:
> On Fri, Nov 15, 2013 at 06:03:25PM -0800, Alan Coopersmith wrote:
> > libX11-xcb only accesses data structures defined in X11 headers,
> > it doesn't call any functions or reference any global variables
> > in libX11 itself.  (Seems to have been left from previous XCL
> > implementation.)
> > 
> > Signed-off-by: Alan Coopersmith <alan.coopersmith at oracle.com>
> 
> That's not the only reason for this dependency.  As you said, libX11-xcb
> accesses data structures defined in libX11 headers.  In particular, it
> relies on the newly added "xcb" field in Display.  Without a dependency
> on libX11, it would be possible for an application to link with
> libX11-xcb and with an older version of libX11 that does not have the
> "xcb" field (and doesn't use libxcb underneath).

That argument doesn't make sense.  Nothing about the way that dependency
is expressed requires a "sufficiently new" libX11.  All that's required
is that it have a soname of libX11.so.6, which even pre-xcb libX11's
had.

If an app bundled a bunch of libraries including libX11, and the bundled
one beat the system one due to LD_LIBRARY_PATH or DT_RPATH or whatever,
and loaded a plugin that used libX11-xcb, the plugin would fail.  You
could not even hope to fix this by making libX11-xcb import a versioned
symbol from libX11, all that would do is move the failure ahead to
dlopen time (since the pre-xcb copy of libX11 would already be loaded).
And it's not just plugins, if _any_ library it didn't bundle ended up
using libX11-xcb you'd hit this failure case.

- ajax