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)
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).
Hmm, I wonder if we broke something in the VS build flags recently
for fltkdll.
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.
Perhaps instead, the generation of fltkdll.lib needs FL_DLL /undefined/
so that WinMain() gets defined in it.
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)
I sniff around to see if I can figure out how the two fltkdll.{lib,dll}
files are generated.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
