Daniel Macks wrote:
[]
>>> This is on 10.5.5/intel+xcode-3.1 with stock Apple X11. This has  
>>> RRNotify defined in /usr/X11/include/X11/extensions/randr.h.
>>>
>>> With xquartz updates, one gets additionally XRRNotifyEvent in /usr/ 
>>> X11/include/X11/extensions/Xrandr.h.
>>>
>>> With xcode-3.0, there is neither RRNotify nor XRRNotifyEvent defined.
>>>
>>> It looks like one has to undefine HAVE_RANDR manually to get a  
>>> consistent behavior.
[]
> 
> I remember seeing an upstream bug...somewhere...about some sort of
> randr incompatibility. Combination of mis-detection and X11 breakage,
> like x11 headers or .pc published a certain version but then actually
> only supplied an older version ("have new version? use new-version
> features.  ==> boom"). Need to correlate user errors with x11 supplier
> (10.4 vs 10.5-apple vs 10.5-xquartz (and making sure to reinstall that
> latter after osx updates))

The gtk+2 configure script tests for xrandr.pc version >=1.2.
On 10.5, this is always true if any 10.5 X11 is installed (on 10.4 with 
Apple X11, it is not true, no xrandr.pc file present, randr.h version 1.1).

Here again the different cases on 10.5.5. There are actually only two 
cases. The third intermediate one I have been seeing must come from 
contamination by an old test of xquartz.

1. Apple X11 with xcode-3.0:
   xrandr.pc version 1.2.2
   randr.h and Xrandr.h are (c) 2002
   randr.h does not define RRNotify
   Xrandr.h does not define XRRNotifyEvent
   gtk+2-2.14.3-1 does not build

2. Apple X11 with xcode-3.1.1, or xquartz version 2.3.1:
   xrandr.pc version 1.2.3
   randr.h and Xrandr.h are (c) 2006
   randr.h defines RRNotify
   Xrandr.h defines XRRNotifyEvent
   (there are other differences in these files between xcode-3.1.1 and 
xquartz, though)
   gtk+2-2.14.3-1 builds

One cannot speak of a mismatch with the libXrandr.dylib version, because 
in all of these cases, although libXrandr is present, the X server is 
compiled *without* the RANDR extension anyway, so that the whole thing 
won't work in any meaningful sense.

I still think it would be best to #undef HAVE_RANDR for the Fink package.

-- 
Martin








-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fink-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-users

Reply via email to