On 2 Oct 2011, at 00:02, Evan Laforge 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?
Indeed, and that's what Manolo has done, and that's fine. But Matt was (I think) pointing out that dynamically loading and using XRandR only if it is available, is also a possibility, and perhaps more portable for the end-user of the binary so created... > 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! Yup, quite agree. The problem is that "static linking" is increasingly mythical - sure, fltk itself will be linked static, but on most host systems now the bulk of the system libraries will be dynamic. OSX doesn't even ship static versions of many libs, and it's increasingly common for linux distros too. And the linkers heavily favour the shared object over the static object, if you let them choose... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
