Comment 62 for bug 86103

(In reply to comment #20)
> Things that happened to work with some versions of Xlib != things that Xlib
> supported.

Yes and no. As previously discussed, the only two definitions of the Xlib ABI are the classic Xlib implementation, and the one in Keith Packard's head. I think the XCB approach of trying to match the ABI as per the contents of Keith Packard's head is a very good one, but at the same time sandmann is justified in complaining that changing the ABI from the one implemented by classic Xlib breaks lots of stuff in ways that aren't easily reparable.

> If you use Xlibint to write an X extension, regardless of whether
> that extension lives in a library or directly in a program, your extension code
> must match the system Xlib's idea about threading.

In the Xlib ABI in Keith Packard's head, I assume that's true, and it certainly seems reasonable. The fact remains, however, that the ABI provided by classic Xlib implements different behaviour for users of Xlibint functionality to the XCB Xlib. Changes in ABI, even just from as-implemented to as-intended, should really be accompanied by a library version change, so that even if the new behaviour becomes the default, the older version is still available to older applications. Linux distributions, for example, can then provide the older version as an optional install to allow old (broken) apps to run properly, or symlink it to the new version to force old (broken) apps to show up as broken.

[snip]

> As you have suggested, building your extension code with XTHREADS may work with
> older Xlibs that do not use XTHREADS. However, building your extension code
> without XTHREADS will break with an XTHREADS Xlib. I understand your argument
> that older versions of Xlib didn't actually use internal locking and unlocking
> code if you didn't call XInitThreads(), and thus you could get away without
> even trying to call them; however, that does not mean that you do not need to
> call the macros which check for the internal lock and unlock function pointers
> and call them if set.

I was the one asking about the XTHREADS issue, not sandmann, actually. As we've established, the issue here is that the difference in behaviour between classic Xlib and XCB Xlib constitutes a change in the presented ABI. Whether that's from as-implemented to as-intended behaviour is irrelevant if the result is that many programs relying on the old behaviour won't work with the new implementation. My view is that this is really a problem with for the Linux distributions to sort out, and of course it doesn't affect my particular project since I can rebuild with XTHREADS to get the required behaviour, but there are going to be people who need to run (broken) legacy apps who will find that they also need XCB-based apps in future, and can't install compatible libraries for both, which wouldn't have been a problem with a library version bump.