On 10.05.2011, at 22:22, Michael Sweet wrote: > > On May 10, 2011, at 8:38 AM, Greg Ercolano wrote: > >> I was noticing yesterday fltk (1.3.x) builds the "fltk" subproject >> in DLL hell mode, ie. with the compiler flag /MD (DLL runtime libs) >> instead of /MT (static runtime libs). >> >> Using /MD creates a situation where the resulting exe ends up >> requiring MSVCRXXX.DLL file in order to run on other machines >> that don't have VS installed. >> >> I'm wondering if: >> >> a) the /MD flag is a good default, given the DLL hell >> it seems to incur on unsuspecting programmers; >> perhaps /MT instead? > > The static libraries have their own problems, particularly if you use FLTK as > part of a plug-in for another application or if you link to any other DLL, > which will be compiled against the dynamic runtime, pulling in different C > runtime definitions that clash with the static libraries... > > Trust me, I've run into too many problems with different versions of malloc > and free getting used, leading to some non-obvious crashes/bugs.
Yes, that's exactly why we decided to use multithreaded DLL linking for VisualC 6 in 1998 or so. Fascinating that MS obviously has not solved this issue in 13 years. Oh, and BTW, linking "multithread DLL" does *not* mean that you have to link dynamically! It merely means that the C runtime is linked dynamically, making sure that all modules use the same basic C functions. FLTK can still be linked statically. The "multithread" option should be self explanatory. Not using "multithread" safe libraries these days would be insane. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
