On 02.10.2011 01:07, Evan Laforge wrote: > On Sat, Oct 1, 2011 at 4:02 PM, Evan Laforge<qdun...@gmail.com> wrote: >>>> I see that libXrandr depends on libX11, libXext, libXrender, and libc >>>> and that libXft depends on all of these and others. Thus, I conclude >>>> that using libXrandr does not require additional libraries >>>> on the platform besides itself. >>>> Is that correct ? >>> >>> I think so - but the key here (as it is for XFT too, of course) is that is >>> it is on your system at build time, the binary will expect to be able to >>> load it (XFT | XRandR) at runtime, and of course this may not be true if >>> you run on a different machine. >>> >>> I think what Matthias was suggesting is that we might be bale to test for >>> XRandR at runtime and load it where it is available, and use it, but if it >>> is not available, then we fall back to the existing behaviour on X11 >>> systems instead. >> >> Isn't the usual thing to define HAS_XRANDR or something and #ifdef the >> the bits that depend on it? >> >> Not that I'm a fan of yet more ifdef, but it seems simpler than some >> dynamic loading malarkey. I like fltk for its bias toward static >> linking! > > Oh sorry, I understand now what you mean. You can disregard the above :) > > I guess if it means a statically linked xrandr using fltk program > would then fail on X11 without xrandr, with no option to compile a > version that works on both, then yeah that would be unfortunate. I > guess some dynamic testing of X's installed extensions would be in > order. But surely that's nothing new for X extensions, right?
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 _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
