On 22.05.2011 18:43, Greg Ercolano wrote:
> Albrecht Schlosser wrote:
>> On 22.05.2011 14:27, asif saeed wrote:
>>> By the way, I guess a conditional compile-time inclusion of the above stub
>>> could be made in in the fltkdll.lib - the lib file that needs to be
>>> specified in Linker/Input setting before comctl32.lib. This way, the user
>>> would still get to write standard main(). Don't you think so?
>>
>> Nice suggestion, but that wouldn't work (otherwise it *would* have
>> been done). The reason is that you can't call any part of the main
>> program from a dll, and as the comment in the FLTK code says, it is
>> not possible to have the program's entry point (WinMain) *in* a dll.
>
> Albrecht: I think VS releases *two* libs: fltkdll.lib and fltkdll.dll
> (Note one ends in .lib, the other in .dll)
Yes, the former (.lib) contains the stubs that will be linked into the
.exe when you want to link dynamically (with the .dll). The irritating
thing is that normal, full, static object libraries are also called .lib
(and internally this may well be the same, an object library). However,
fltkdll.lib allows the linker to link an executable without resolving
the *real* functions - instead it links with the __imp_* stubs that are
needed to call the real functions when the .dll is loaded. This is also
called an import library.
So, in short form:
- fltkdll.lib is used as the linker input library if you want to link
against fltkdll.dll, and
- fltkdll.dll is used at runtime (loaded when the program is started)
I apologize if this is all known or maybe not 100% accurate...
> I think what Asif is suggesting is the .lib version of fltkdll
> do the WinMain() include (which it may be doing, or should be
> doing, I'm not sure).
This would be an interesting idea, but I don't know how to do that.
Maybe it could work, but how to do it with the VS tools, I don't know.
> Hmm, I wonder if we broke something in the VS build flags recently
> for fltkdll.
I don't think so.
> I don't at all understand how both fltkdll.dll and fltkdll.lib are
> generated, but it's beginning to sound like maybe both have FL_DLL
> defined on build, leaving WinMain() undefined.
They are generated in one step by the Microsoft linker's magic. The
import library contains the identical symbols as the .dll file (a 1:1
relation), with the difference that the former has the __imp_* stubs
and the latter the real functions.
> Perhaps instead, the generation of fltkdll.lib needs FL_DLL /undefined/
> so that WinMain() gets defined in it.
There is no difference in the build process, see above.
> Our lib/README.txt probably needs updating to cover what fltkdll.lib
> is, when and how it should be included, and what magic compile/link
> flags should be specified to link a DLL version of an FLTK app. (eg. /D
> FL_DLL)
Yes, there should be better documentation. Matt started documenting how
to create a simple project with FLTK in README.MSWindows.txt (paragraph
"Creating new Projects"), but that's terse and only for static builds.
> I sniff around to see if I can figure out how the two fltkdll.{lib,dll}
> files are generated.
As I wrote (both in one step), and as Nikita wrote meanwhile, there is
an option for the dir. and name of the import library.
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
