Hi, Depends from the platform sdk reveals that osgconv.exe is not linking with osgViewer.dll because by default there are no symbols to be resolved from it due to the decoupled mechanism used to get a context.
Other proxies in e.g. the openflight loader will be constructed because the library is explicitly loaded or because there are exports that are used in the final executable. I have no idea how to force it to obey the user in the first place, since osgViewer is both a project dependency and explicitly specified on the linker additional dependencies line. Using /OPT:NOREF has no effect, as do various combinations of function-level linking, declaring the proxy as an export, in the header... As it turns out, forcing any old reference by say calling osgViewer::osgViewerGetLibraryName() at the top of main is sufficient to set things right. Would this be any more acceptable? Cheers, -Tony Robert Osfield wrote: > On 11/2/07, Argentieri, John-P63223 <[EMAIL PROTECTED]> wrote: > >> Luigi, >> >> You and I both know that that will work. Since Robert doesn't like that >> solution, I'm not going to bother. >> I'm not as noble as some--I have my own software to write. >> > > Well I want to fix the problem properly that's all, adding a locally > constructed Viewer object might work but its a hack that hides the > real issue - why Windows/VS is not automatically constructing the > proxy registration object in osgViewer/GraphicsWindowWin32.cpp. If > one can fix this then osgconv should just work. It might require a > different compile option. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
