XOrg-7.2 - libXcb

Dan Nicholson dbn.lists at gmail.com
Tue Jul 3 07:38:30 PDT 2007


On 7/3/07, Randy McMurchy <randy at linuxfromscratch.org> wrote:
> Alexander E. Patrakov wrote these words on 07/02/07 09:46 CST:
> > Dan Nicholson wrote:
> >
> > Also please make it clear that this is a workaround and that the bugs are
> > not in libxcb, but in applications.
> >
> >> Well, why don't I work on the 7.2 updates first? libX11-1.0.2 needs a
> >> patch, right?
> >
> > Yes. AFAIK, this and
> > http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8
> > are the only known brown paper bag bugs in this version.
>
> I'm trying to follow this thread, but I'm a bit confused as to what
> exactly is broken. Is the bottom line that the BLFS instructions for
> installing Xorg-7.2 are broken and shouldn't be used?

Sure, I'll be glad to have another opinion here.

Our instructions are fine (besides a couple versions Alexander pointed
out that have bugs and should be updated), they're just not using the
full official way of libX11 on libxcb.

> Or is eliminating libxcb a solution that works and has no affect on
> other packages down the road?
>
> I'm asking because on the Xorg site, it says that libxcb is now an
> official part of Xorg-7.2, but we aren't installing it.

It's actually fairly simple to switch back and forth using libxcb. You
might recall that the original use of XCB was to have it replace
libX11 (Xlib). But Xlib has been around forever, and the transition
would take a long time if at all. So, currently what happens is that
libxcb provides the transport layer for libX11. So, applications still
see and link to the libX11 interfaces, but in the background libxcb is
doing most of the work.

With libX11-1.1.0, the default is to link to libxcb unless you pass
--without-xcb. This makes libxcb part of the official Xorg
distribution. But you can easily go back and forth if you install
libxcb and rebuild libX11 --with{,out}-xcb. That's the only part of
Xorg that uses XCB.

Why this matters is because the XCB developers made the decision that
they would assert() on some bugs in applications. This is different
than the old libX11 behavior where it would just carry on. Now, the
application is just going to crash. The specific case of locking the
display is causing some apps to suddenly start bombing on assertions.

Now you've got things like the binary java and skype crashing when
they "worked" before. The solution is to tell them that they're using
Xlib wrong and always have, it's just being enforced now. But, what do
you do in the meantime?

Alexander and I have tossed back a couple ideas of how to handle this
since we'd like to have libxcb in there.

* Disable all the assertions by using -DNDEBUG. Not probably the
wisest choice and definitely frowned on by the XCB developers who made
the conscious decision to leave the asserts in all the time.

* Make them more conditional. The popular distro solution is to make
the asserts conditional on an environment variable, XCB_SLOPPY_LOCK I
think. Then you can work around things. I think this is probably the
best compromise, and I think Alexander does, too.

* Just leave it as is. I personally haven't had any problems yet. The
crash in java is in a corner case where you're using the mawt module
and you have XINERAMA enabled in the xserver. I also haven't seen the
skype crash firsthand (I haven't used it in a while).

Hope that sums things up. You have an opinion on the matter? Keep in
mind that those last patches that Alexander pointed to are a separate
issue that will be addressed soon. Using the libX11 in the book right
now should be fine.

--
Dan



More information about the blfs-dev mailing list