On 14 Mar 2010, at 12:01, Simon Lewis wrote: > Currently Fedora 12 ships with fltk 1.1 libs (currently 1.1.9 with > 1.1.10 in testing) > > It is not possible to install 1.3 libs as a number of programs > including Zynsubaddfx, html2doc etc.. depend on the 1.1 version libs.
Yup - this is a tricky one. In what sense "not possible", though? The kicker is that the fltk-1.1 and the fltk-1.3 .so files and header files have the same names, but comprise a subtly different API and an incompatible ABI... So code that links dynamically, and was built for the 1.1 ABI, will link at runtime to the 1.3 .so files, but then die horribly in strange and mysterious ways. But... I have 1.1, several version of 1.3 and also fltk-2 installed on my main linux dev machine, and it works OK. The key, of course, is to only put one version in the "system" places (1.1 in my case), and then use "configure --prefix" option to put all the others in version specific places. This works Very Well for statically linked builds, and with a bit of fiddling about with paths and env vars, works OK for dynamic linking too. But it is unlikely this would *ever* fly for the distro packagers - though for dev use it is simple enough. I'd quite like to make the fltk-1.3 libs be called libfltk-1.3.a / libfltk-1.3.so etc... I already make a symlink to rename fltk-config to be fltk1-3-config (etc.) I don't have a really idiot proof solution for the "clashing" 1.1/1.3 header files though - I do that all via paths, so there is still the potential for the wrong header to be linked against. > To be able to recompile Zynsubaddfx against fltk 1.3 I require a > tool to parse the Zynsubaddfx source code (ui files only) and make > the necessary changes e.g colour depth from 24bit to 32 bit, I don't understand why that change is necessary, to be honest. What are you doing with this? I've ported a load of code from fltk1-1 to fltk1-3 and don't recall ever doing anything about colour depth. > Fl_Scroll::scroll_to instead of Fl_Scroll::position, Yup, that's a hard one, but the fltk-1.3 way makes more sense and is more consistent with the rest of the API. > ASCII <--> UT8, etc.. Do you support a lot of non-english text? If so, this is a pain Right Now but probably a win in the longer term. If your text is mainly english, of course, then UTF8 == ASCII and there is no effort required. > If this is not possible than fltk 1.3 should really be renamed > fltk3 to allow both libs to live side by side... I doubt that we'd go for calling this fltk3. fltk1.3 or something, maybe... There might even be a true fltk3 sometime soon (or at least, hopefully before the sun enters its red giant phase, anyway) as there is already some work underway in that direction, as an attempt to un- fork the fltk1 and fltk2 families. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
