In recent versions of Xlib, the default configuration options enable a "feature" (i.e. a deliberate bug) in XCreateGlyphCursor. Specifically, the function is redirected to XcursorTryShapeCursor in libXcursor, which may ignore the source_font and mask_font arguments, and use some other font instead. Essentially, the idea is to forcibly retrofit themed cursors into existing applications. The consequence is that XCreateGlyphCursor no longer behaves as documented or expected (programs and libraries which want themed cursors will be using ilbXcursor directly), and there is no way for the application to force specific cursors (e.g. those shown in printed documentation) to be used. The fix is straightforward: pass --disable-loadable-xcursor to configure, e.g.: --- /usr/portage/x11-libs/libX11/libX11-1.1.4.ebuild 2008-07-03 03:09:13.000000000 +0100 +++ /usr/local/portage/x11-libs/libX11/libX11-1.1.4-r9.ebuild 2008-07-19 15:51:33.000000000 +0100 @@ -26,7 +26,8 @@ >=x11-misc/util-macros-0.99.0_p20051007" CONFIGURE_OPTIONS="$(use_enable ipv6) - $(use_with xcb)" + $(use_with xcb) + --disable-loadable-xcursor" # xorg really doesn't like xlocale disabled. # $(use_enable nls xlocale)
I'll side with upstream here. I agree it'll break some old X apps who do use custom cursors, but those really aren't my priority anymore. If there are applications in portage who still rely on XCreateGlyphCursor, a bug should be opened to make them use libXcursor instead. If you really don't like this new behavior, I suggest you keep a modified libX11 ebuild in a local overlay. As there are very few libX11 releases these days, it really shouldn't be too much trouble for you. Thanks
