(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
