The XrandR library is very likely installed on all modern Linux machines 
(ie ones that can do xft). It is required by Qt and GTK. I don't think 
there will be any problems requiring it.

On 10/02/2011 03:47 AM, Matthias Melcher wrote:
>
> On 02.10.2011, at 12:28, Manolo Gouy wrote:
>
>>>
>>> I believe the proper solution is not only to add a configure check
>>> whether the libs exist on the build system (as Manolo did, IIRC [1]),
>>> but also to add a configure option (--enable-xrandr) so the developer
>>> can decide to build with or without the extension library, even if it
>>> exists on the /build/ system.
>>>
>>> This is consistent with --enable-xft (currently the default) and makes
>>> the developer who builds the app responsible for selection of extensions
>>> that his app requires on the target system (or not).
>>>
>>> Then there wouldn't be a need to load any required libraries dynamically...
>>>
>>> This ought to be done for 1.3.2, whereas 1.3.1 should build w/o
>>> xrandr as suggested elsewhere.
>>>
>>> Albrecht
>>>
>>> [1] I didn't check the development closely recently, maybe I'm wrong
>>
>> The --enable-xrandr option is there (run ./configure --help).
>> What's missing is the CMake equivalent.
>
> Xrandr will not make it into 1.3.1 . 1.3.1 will be exactly 1.3.0 plus any 
> patch we did on *crashing* or *hanging* bugs. Anything else will not be in 
> 1.3.1, but eventually in 1.3.2 .
>
> As for Xrandr, if I understood this correctly, it can remain statically 
> linked and still run an machines that do not have Xrandr installed. X11 is a 
> network protocol that defines communications between the server (the display 
> or terminal), and the client (the application). It was meant to send graphics 
> commands from a "dumb" terminal to an app running on a mainframe. Now if we 
> send Xrandr requests from the app, the X11 server should simply return "bad 
> value", and FLTK should react appropriately. We should verify that this 
> works. Xft should behave the same way - has anyone ever tried that?
>
> So, yes, static linking should be fine.
>
>   - Matthias

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to