(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. 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() 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. I'm thinking this is how it must have worked, but I'm not sure. 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> Strictly speaking, statically linking any part of an LGPL library triggers section 6: http://www.gnu.org/licenses/lgpl-2.1.html Section 6 is an exception specifically for closed source apps that statically link. In the case of a static link, the app developer must also meet ONE of the five options in section 6 (paragraphs a thru e) which lists things like supplying a dynamic version of the executable as well, or a way for the end user to link against a dynamic version of the lib (eg. providing .o's and a linker script) Apparently section 6 is intended to allow the end user an option to build their /own/ version of the lib, and make use of it with the closed source app. This is an LGPL /requirement/, and large vendors with lots of antsy lawyers take this very seriously. Apparently many commercial vendors (large ones, like Autodesk) take the DLL route to avoid triggering the LGPL static link exception. Maya is an example I have verified, which makes use of many LGPL libs. There was a long thread on this subject on a very large 3D related mailing list I'm on which includes a lot of devs from commercial vendors which essentially outlined the commercial software vendor point of view: o Static linking against an LGPL library creates difficult requirements for commercial vendors, specifically section 6, paragraphs a-e. (Whether a-e is actually "difficult" is debatable. But several devs from different vendors chimed in about this, citing legally vague situations) o Dynamic linking avoids section 6, so they prefer to use that. o DLL hell "no longer exists" (I beg to differ) and hasn't existed for years; put the dll in the same dir as the executable, and problem solved. For linux, a wrapper program sets LD_LIBRARY_PATH to point to the dir where their dll's are) Regardless of the debatable aspects of the above, it's true that the LGPL does make an exception for static linking, and a 'pure' DLL version of the lib therefore needs to be an option for someone wanting to avoid section 6, whatever the reason. So if the above fltkdll.lib option solves WinMain(), we should probably still include directions to the app dev for how to put the WinMain() definition into their program, or make the WinMain() code/lib 'public domain' so as not to trigger LGPL section 6 if statically linked, and cite that in the docs as a way to avoid section 6. </LGPL ISSUE> _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev