On 24.05.2011 at 17:55, Greg Ercolano wrote: > (Moving the fltk.general thread "Link Errors / Visual C++ 2010 Express" here) > > Asif writes: >>> May be you can name such header dll_linked_app.h or something like that. > > Albrecht writes: >> I think that winmain.h is a good choice, isn't it? > > This would mean the user program would have to have an #ifdef > in their main.cxx to handle a DLL vs non-DLL build, which is a > detail I'd think we should want to avoid if we can.
You don't need a #ifdef if you use my example header file, you must only #include this _and_ define FL_DLL before the inclusion (usually via the command line) if you want to build a DLL version of your program. This is a documented requirement not only in the main program but in all source files that call FLTK methods/functions. That's what FL_EXPORT is for: it is defined either as __declspec(dllexport) inside the library to _export_ the symbol names or as __declspec(dllimport) in the user program to _import_ the symbol names depending on FL_DLL where "import" technically means that the function or method or variable name gets something like "__imp_" prepended (and maybe more). But this is what you can see if you get linker errors because you missed the import library for the dll. > My thinking on how this all worked before: > > fltkdll.lib -- has WinMain(), no fltk code (basically a /very/ small > static lib) > fltkdll.dll -- has the fltk code, but no WinMain() I don't know how "it worked before", but fltkdll is the import library for fltkdll.dll, and as such it is (something like) statically linked because it only contains the stubs for calling the real functions in fltkdll.dll. > An app wanting dynamic fltk would /statically/ link against fltkdll.lib > just to get the WinMain() definition, and the dll would come via the > usual route. For linking see above. It would be interesting if we can *add* our version of WinMain() to the fltkdll.lib import library to solve this problem. Maybe this is possible with MS/VC++ tools, but I don't know how. Is there an equivalent for the gnu ar program? Or is this .lib file format compatible with gnu (gcc) object library formats so that someone who wants to try it could manage this with ar ? ... <side note> BTW.: another option we discussed already is to tell the user to link dynamically with the dll (fltkdll.lib -> fltkdll.dll) *and* statically with fltk.lib, just for the reason to extract our WinMain() function. </side note> > I'm thinking this is how it must have worked, but I'm not sure. I never tried the dll way myself as a user, and so I can't tell if it worked like this "before". But we have a time machine called subversion, so you can try if you like... ;-) > Assuming that works, the only thing that might be wrong with this > (having a small static link stub to access the DLL) would be an > LGPL issue, believe it or not. > > <LGPL ISSUE> [...] > </LGPL ISSUE> IANAL, but... Our FLTK library allows to link statically as an explicit exception, so why wouldn't it be allowed to link most of FLTK dynamically (DLL) and a small part (WinMain()) statically ? Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
