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
