Hi Ian, I do not get a black debug window if I link statically with FLTK using a release config. Building a DLL of FLTK and trying to use it in release or debug mode always shows me the debug window even though I am not supposed to debug in release mode. The debug window is nice in debug mode but it should not show up in release builds whether I link with FLTK statically or via a DLL.
Regards, Asif On Sat, May 21, 2011 at 12:41 AM, Ian MacArthur <[email protected]>wrote: > > On 20 May 2011, at 15:30, asif saeed wrote: > > > I build fltkddl using the debug configuration. I got an FLTKDLLD.DLL file > in > > the TEST directory. But the compiler cannot seem to FIND that > FLTKDLLD.DLL > > file in the TEST sub-directory of FLTK - E:\libs\fltk-1.3.x-r8514\test. I > > specified this directory in the PATH environment variable but no success. > I > > have also tried specifying the path (PATH= E:\libs\fltk-1.3.x-r8514\test) > in > > the Project Settings/Debugging/Environment option - no success. I need > your > > help. > > No, you need the help of someone who knows how to set up the MS toolchain > and use it to build your code; the problems you are having are not fltk > problems, they are problems with your build configuration. > > You need tpo step back a bit, look at how all the bits fit together, then > take a fresh run at things. > > Things you need to keep in mind when investigating these problems are: > > - Mixing fltk and MFC is likely to be painful > > - fltk works fine when built with the MS VC tools, in both static and dll > modes; many people use it. Any problems you are having are particular to > your configuration, and it is there we must look first for solutions. > > > > Basically, I need to keep the executable size small and have to run many > > instances of my executable. so must use a DLL for low memory consumption. > > This may be a fallacy; it is widely assumed that building for DLL will > result in smaller exe's and more efficient memory use. However, depending on > the complexity of your application, that can turn out to be very far from > the truth. > > - The way Windows handles process spaces, it is far from certain that > multiple instances of your code will in fact use a single instance of the > DLL - so you might end up loading several instances of the DLL, which will > use much more RAM than the static instances would. (This is true of many OS > of course, not just Windows.) > > - If your code is static linked, then the linker will only include those > parts of the lib/DLL that are actually used, and all the unused symbols and > inker info will be stripped too. A DLL build must load the entire DLL and > must retain the linkage information until runtime. So if your app only uses > a subset of the fltk lib, linking it in statically will usually result in a > substantially smaller RAM footprint than the DLL build. This may seem > counter-intuitive, but it true nonetheless. > > - In short; never assume that the DLL build will use less resources. That's > classic premature optimisation. If you actually care about resource > utilisation, then MEASURE it explicitly to determine what is truly best for > your use case. > > > > > _______________________________________________ > fltk mailing list > [email protected] > http://lists.easysw.com/mailman/listinfo/fltk > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
