Test Results for Xinerama and JDK6

Dan Nicholson dbn.lists at gmail.com
Tue Jun 26 22:39:05 PDT 2007

Thanks! I couldn't reproduce this myself and felt wrong pushing in xcb
without testing.

On 6/26/07, DJ Lucas <dj at linuxfromscratch.org> wrote:
> I don't know whether this is an xorg problem or a sun problem as I
> haven't reviewed it more than the simple test case that Dan had dug up.
> Anyway, the binary JDK failed, the source-built passed, or at least
> didn't display the assertion, I just realized I didn't check the return
> value...shouldn't matter.

Thanks really goes to Alexander for digging into the test cases and
solutions a bit further. So, if the source is OK with no fixes, then
that's great. I would have thought you'd need a similar fix to the
s/XINERAMA/FAKE/ to the binary. Let's just leave it as is for now and
assume it's OK until someone can reproduce the issue.

> For the binary crowd, is it really OK to sed out Xinerama in the
> distributed one?  Or, should I look at building a replacement libmawt?

I think it's OK to do the sed on the binary.

The other wide ranging fix is just to remove the assertion from
libxcb, as this is new behavior and the old libX11 didn't assert on
locking errors. Thus, why these issues are coming up. I think this
might be the right idea in the long run. I just saw another bug the
other day for skype, and good luck finding the source of the issue for
that or any way to fix it. In that case:

# remove all assertions
CPPFLAGS="-DNDEBUG" ./configure ...

# just the xcb.lock assertions
sed -i 's at assert.*lock.*@/* & */@' src/xcb_xlib.c

Some of the distros also have a patch allowing you to set an
environment variable LIBXCB_ALLOW_SLOPPY_LOCK. Here's the suse commit:



More information about the blfs-dev mailing list