libXcursor and its dependencies

Kristian Høgsberg krh at
Mon May 7 16:31:38 PDT 2012

On Mon, May 7, 2012 at 5:57 PM, Andrew Guertin <andrew.guertin at> wrote:
> There's been a bunch of talk recently about libXcursor and its
> (potentially unneeded) dependencies. There was some talk about splitting
> it up, and/or creating a libwlcursor. I looked into this a bit, and
> found the following:
> Every function in the api (in Xcursor.h) falls into one of two categories:
> 1) Reading and writing cursor files, or
> 2) Dealing with X: checking server capabilities, telling the server to
> use a cursor, etc.
> The two categories are even quite well split up: most files contain
> implementations of functions from only one category; only one file
> implements functions from both categories.
> Based on this, I think it would, in fact, be quite easy to solve the
> problem of unwanted dependencies. There are two possible solutions I can
> see:
> i) Split libXcursor into two libraries, with the X-related one depending
> on the non-X-related one
> ii) Add a configure option to not build the X-related code
> ii would be extremely easy; i would require a bit more thought in terms
> of how it would affect packagers and eventual work to deal with
> infrastructure and get the new library in distributions.

Either would work, I think the main concern is what is most acceptable
upstream.  If we do  ii, we need to make it build a differently named
library and maybe use a different prefix for the symbols.  GTK+ might
link to both libXcursor and the wayland version of the library in case
it's compiled with support for both X and Wayland.  Also, building two
different libraries from the same source often requires a bit of
packaging (rpm/deb) ad-hoc scripting,  so from that point of view i is
easier.  We could just split the library and have libXcursorfile with
just the loading code and libXcursor with the Xrender integration and
link that to libXcursorfile.  That way, current libXcursor users work
the same and we can just use libXcursorfile in Wayland.


> Thoughts? Opinions?
> --Andrew (dolphinling)
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at

More information about the wayland-devel mailing list