| 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. |
| | 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. |
