DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2522 Version: 1.3.0 -1 on using FL_LIBRARY for Windows, i.e. we should change FL_LIBRARY to another name for this purpose, as discussed in fltk.development, and this should be done for *all* platforms, IMHO. Sorry for the inconvenience, but I don't think that it would be wise to use FL_LIBRARY now that we know that it can make problems. > All VisualC projects should be modified also to define FL_LIBRARY > when compiling libfltk, libfltk_gl and libfltk_images, > but not for any other target (not even fluid). That should already be so, since this was the original purpose of FL_LIBRARY (together with FL_DLL) for the Windows shared (aka DLL) VisualC version. > Could someone commit these changes and modify MSWin IDE projects > accordingly ? -1, please wait a moment. I'll have a look at it and propose a change later tonight. > Did I understand well that, with VisualC, application programs > compiled with -DFL_LIBRARY to get access to the Fl_X class > would fail at link time or run time ? Yes, that would be the case when building the DLL versions, for the lib itself as well as the user programs. You must define FL_DLL if you want to build a user program that links to the FLTK dll when building with VisualC to get the correct name mangling or whatever to find the dll functions. This does not work if a user program defines FL_LIBRARY. I believe that this can be done better by defining another Macro. e.g. FL_INTERNALS, or FL_USE_XID or similar, and that we expose Fl_X if either FL_LIBRARY or the user-defined Macro requests it. I'll make a proposal later... Link: http://www.fltk.org/str.php?L2522 Version: 1.3.0 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
