GNOME Bugzilla – Bug 115996
configure fails to find Xrandr extension
Last modified: 2004-12-22 21:47:04 UTC
configure fails to find the Xrandr extension. Checking config.log shows that this is caused by it not linking libXrandr together with libXext. In the non-Solaris case, configure greps $ALL_X_LIBS for -lXext to figure whether libXext need to be linked. However, it never checks whether there is a libXext (ALL_X_LIBS is never properly initialized beyond setting it up to have -lX11), so the check for libXrandr would always fail on a non-Solaris X11R6. This applies to both metacity 2.4.55 and 2.5.2.
Created attachment 17823 [details] [review] Proposed patch to fix the bug
not sure what you mean. Configure certainly manages to find randr on my xfree86 running on debian/i386....
I guess this is really two bugs in one. Certainly it doesn't occur in the usual case, since no one else has noticed it (as the previous comment shows). First, in *my* system, configure can't find Xrandr. Discussion on bugzilla.ghostscript.com shows that these links fail because of my incomplete transition to libc6; i.e., the failures only occur on systems where the libraries/headers are not in the "usual" places. You could arguably say that this is the user's problem. But I would say this will be reproducible if you are transitioning from libc5 to libc6 and have your libraries/headers in the "wrong" places. However, secondly, the existence of the grepping of -lXext in $ALL_X_LIBS in configure shows that the intent is certainly that $ALL_X_LIBS should contain -lXext if it is needed, but the code won't allow it because $ALL_X_LIBS is never initialized properly. This certainly is a bug in the code in configure, a failure to initialize a variable (namely $ALL_X_LIBS). The point is that fixing the second sub-bug (the data initialization error) fixes the first sub-bug. I certainly see the "second sub-bug" as a real bug.
OK, you've sold me. I certainly don't see how if could hurt to apply the patch. Hopefully Havoc will give his OK soon.
ping
I think the "right" fix here is to just add -lXext to the AC_CHECK_LIB for Xrandr, next to -lXrender By "right" I mean "most consistent with the current setup" However the current setup is pretty clearly a mess.
removing PATCH keyword since the PATCH isn't quite right.
Fixed in CVS. Someone ought to clean up all those checks for real, but not a high priority.