DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Regarding ABI issues WRT (C++) fl_filename_list(), Michael wrote: "I have tried to statically link code that use the new 'filename.H' against an older library and this fails because the parameter types of the C++ function do not exactly match." This is not the really the ABI problem we're talking about. If you compile with a new library (i.e. its header files), then this is NOT supposed to link and work correctly with an older library. The important part is the other way around: if you have an old program, linked dynamically against an older library (Windows DLL, U*X shared object), THEN it must still work with a newer shared library. This means that all previously existing functions/methods must still exist in the new library and be compatible. Michael continued: "... is it possible to overload the function declaration without breaking other things?" I know that we have such overloaded functions/methods with different const-ness in some parameters. So, in theory, it should work if we kept the old non-const (C++) function name(s) and add another const-correct version, maybe as a pure C function (wasn't this another change you, Michael, did?). This could probably work, but I'm not absolutely sure. In this case the old function can simply call the new function, if this is possible (maybe by casting the arguments). Hint: a *test* could be to compile and _link_ a program dynamically with an old shared library and _run_ it (maybe on another system) with the new shared library. That's what typically happens if you have built your program on a Linux system with fltk 1.3.0, then you upgrade the system, and this installs fltk 1.3.3 (the next version, maybe with this patch). Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
