Bug 18859 - Need fallback for x11 detection
Summary: Need fallback for x11 detection
Status: NEW
Alias: None
Product: ConsoleKit
Classification: Unclassified
Component: Daemon (show other bugs)
Version: unspecified
Hardware: PowerPC Mac OS X (All)
: medium normal
Assignee: william.jon.mccann
QA Contact:
Depends on:
Reported: 2008-12-02 21:42 UTC by Daniel Macks
Modified: 2018-02-08 06:17 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Fall back to autoconf standard for x11 detection (799 bytes, patch)
2008-12-02 22:42 UTC, Daniel Macks
Details | Splinter Review

Description Daniel Macks 2008-12-02 21:42:46 UTC
Building ConsoleKit-0.3.0 on OS X 10.4, whose x11 calls itself "X11 1.1.3 - XFree86 4.4.0" (I think that first part is apple's package installer-bundle versioning?):

>checking for TOOLS... configure: error: Package requirements (x11 >= 1.0.0
>  glib-2.0 >= 2.7.0
>) were not met:
>No package 'x11' found
>Consider adjusting the PKG_CONFIG_PATH environment variable if you
>installed software in a non-standard prefix.
>Alternatively, you may set the environment variables TOOLS_CFLAGS
>and TOOLS_LIBS to avoid the need to call pkg-config.
>See the pkg-config man page for more details.

Apparently x11.pc was a (relatively) recent addition to x11. Other packages have a fallback to using vairous autoconf tests for x11 if pkg-config fails to find it. I could use (as it says) the TOOLS_* vars, but then I'd have to know the glib-2.0 flags myself (which are often complicated) rather than just some standard /usr/X11 paths and -lX11. At a minimum, would be great if x11 were unbundled from the glib-2.0 test, so that I could manually pass my x11 flags (X11_* or so) to override x11.pc, and then pkg-config's glib-2.0.pc would be prepended to accomplish the full TOOLS_* set. Probably more work and less standard than just using ac's own tests though.
Comment 1 Daniel Macks 2008-12-02 22:42:30 UTC
Created attachment 20754 [details] [review]
Fall back to autoconf standard for x11 detection

Maybe not pretty, but Works For Me(tm).

Finds x11 on my machine with no x11.pc and winds up with Makefile variables:

TOOLS_CFLAGS = -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include  -I/usr/X11R6/include
TOOLS_LIBS = -L/sw/lib -lglib-2.0 -lintl  -L/usr/X11R6/lib -lX11

which looks correct, and the various x11-related source files (tools/ck-get-x11-display-device.c and tools/ck-get-x11-server-pid.c) compile with no warnings, and linking doesn't fail due to unresolved XOpenDisplay symbol.
Comment 2 Ray Strode 2009-07-20 13:32:40 UTC
Is this something you still need Daniel?
Comment 3 Daniel Macks 2018-02-08 06:17:34 UTC
Sorry, didn't notice the followup. But to answer, "no". OS X's standard x11--via XQuartz--has had x11.pc for at least the past several years and on several of the most recent major OS X releases. Feel free to close.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.