Changes between Version 17 and Version 18 of Community/Tasks/Win32StaticLink

Show
Ignore:
Timestamp:
07/20/07 12:34:08 (7 years ago)
Author:
martin (IP: 81.178.2.19)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Community/Tasks/Win32StaticLink

    v17 v18  
    5353Using function-level linking instead of object level linking, significant size savings are possible. My application went from 4+Mb of EXE (692k) and DLLs (3.45Mb) to a 2.2Mb EXE. The EXE got bigger by incorporating the necessary contents of the DLLs, but the overall package got much smaller because large portions of the DLLs weren't used/referenced, and were omitted by the linker. 
    5454 
    55 Unfortunately, this technique is at odds with the clever automatic-registration technique OSG uses to register available plugins. This technique relies on the DLL instantiating all global objects within the plugin at the moment the plugin is forcibly loaded into memory by the osgDB code. Other than the call to load the DLL, the osgDB never directly refers to any data/code members of the DLL. As a result, when you compile the plugins as static libraries, you eliminate the explicit DLL load action. As well, since there are no direct references from osgDB (or your main application) to any data or code members of the plugin, the linker cleverly decides it is not necessary and omits all of the plugin from your final EXE= Not what you want. 
     55Unfortunately, this technique is at odds with the clever automatic-registration technique OSG uses to register available plugins. This technique relies on the DLL instantiating all global objects within the plugin at the moment the plugin is forcibly loaded into memory by the osgDB code. Other than the call to load the DLL, the osgDB never directly refers to any data/code members of the DLL. As a result, when you compile the plugins as static libraries, you eliminate the explicit DLL load action. As well, since there are no direct references from osgDB (or your main application) to any data or code members of the plugin, the linker cleverly decides it is not necessary and omits all of the plugin from your final EXE. Not what you want. 
    5656 
    5757The first step in solving this problem is to determine the name of the specific "registration object" that each plugin normally would rely on executing at DLL load time. We must determine the C++ [http://support.microsoft.com/default.aspx?scid=kb;en-us;126845 mangled] name for this registration object, in order to tell the linker to forcibly include it (and all everything it refers to, recursively) in step 8. There are various ways to do this. The easiest one that I know of is to use the dumpbin tool supplied by Microsoft (per Ben Crossman's osgusers message of Oct 11th, 2004):