[Xcb] Patches to build X11 w/ XCB on Sol

[Jamey Sharp]

On Sun, Apr 03, 2005 at 10:21:04AM -0700, Travis Spencer wrote:
> With much Web surfing, patching and some hacking, I was able to build
> X11 with XCB on Solaris 9.

Cool! That's very exciting.

> I ran into these problems:
> 
> 1) getpwnam_r was being called with the wrong number of parameters.
> 2) There were some problems with IPv6 stuff.

I don't recall touching anything related to those bits to create the XCB
support. It sounds to me like you've found build bugs in Xlib itself.
You might try building without '--with-xcb', confirming that these bugs
still appear, and filing bug reports at bugs.freedesktop.org.

If you're feeling ambitious, you could check whether the X.org version
of Xlib still has these same bugs; if they've been fixed there, you
could find out how cleanly their patches apply to the modular Xlib
sources.

> 3) PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP was unsupported.
> 
> The third problem is probably no surprise; we talked about it a little
> on Friday.  I'm not sure if my fix is correct, so make sure and have a
> good look at it.  I don't know much about threads, but I surfed around
> and concluded that using PTHREAD_MUTEX_INITIALIZER when
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP isn't available is an OK thing
> to do.

I'm pretty sure it isn't OK, but you can test it with the attached
program. If the program halts (which it's supposed to do quickly) then
your patch is fine. If it hangs, we'll have to do something else. You
need to make sure libpthread is linked in or the test won't be valid;
the command I used is:
	gcc -Wall -lX11 -lpthread rec-lock.c -o rec-lock

However, the fix is pretty easy. The _NP in the initializer name
indicates a "non-portable" extension, but we had a plan to implement a
more portable alternative where needed. On systems supporting the UNIX98
standard, which quick inspection reveals includes Solaris, the first two
lines of _XInitDisplayLock can be replaced with this code (untested, but
I think correct):

	pthread_mutexattr_t attr;
	pthread_mutexattr_init(&attr);
	pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
	pthread_mutex_init(&XCBConnectionOfDisplay(dpy)->iolock, &attr);
	pthread_mutexattr_destroy(&attr);

The reason we don't want to do this on Linux is that the
pthread_mutexattr functions are only available if you link against
libpthread, which the majority of Xlib apps don't need and so kind of
don't want. It doesn't look to me like Solaris has the same problem,
though, so we should be in good shape there.

BTW, I just read that Solaris support for recursive mutexes was
introduced in version 7, though it was buggy.

On another note, there are some interesting points about recursive
mutexes that may mean Xlib/XCB isn't correct anyway; see:
http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rec-lock.c
Type: text/x-csrc
Size: 204 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050403/738215f7/rec-lock.c