Hi Robert, A clean build went through earlier today (including wrappers). This time with vc90. The results were the same - I just get the cow when running osgstaticviewer singlethreaded. I haven't had time to investigate why the multithreaded modes don't work, I haven't even had time to up the osg_notify_level and see what's reported there.
The results I get from running with multithreaded modes is "broken mirrors" (lines and points everywhere). Hardware and drivers are the same as my previous static build with vc80 so could still be driver related. Is there anything you would like me to try or some special information you'd like me to produce regarding the static build? cheers Mattias On Mon, Dec 15, 2008 at 8:21 PM, Robert Osfield <[email protected]> wrote: > HI Mattias, > > On Mon, Dec 15, 2008 at 5:57 PM, Mattias Helsing <[email protected]> wrote: >> The results I got were a bit unclear so I was not sure what to report :-) >> >> On the good side - I can view the cow.osg with the staticviewer. On >> the bad - only with --SingleThreaded. >> >> After a rebuild I started the viewer with cow.osg and got "broken >> mirrors". I'm not using the latest nvidia drivers so don't know is >> these are at play. Running single threaded works fine. >> >> After this I checked my visual studio projects to make sure my /OPT >> setting was there and it wasn't. So im thinking that it was the >> rebuild that fixed the problem. I need to start a fresh rebuild to be >> sure. I can't start that until tomorrow. Get back as soon as I can > > OK. Not sure what to make of the results so far... look forward to see > how you get on with a frash build. > >> On a related thought. How should we handle the applications in static >> builds. Using the current setup with static plugins, either osgviewer >> nor osgconv will be very interesting. Should they be excluded from the >> build? Looking at it from the other end one might argue that the >> plugins should always be shared objects (or they are not really >> plugins). Asking stupid questions is one of my strengths but flame me >> nicely ;-) > > osgviewer, osgconv and osgfilecache and osgarchive are general purpose > apps that rely on the plugins to provide the bulk of their abilities. > osgversion would be OK though. I'm just tweak the > applications/CMakeLists.txt to reflect this and will check in once > I've done a clean static build. > > In the examples directory only the osgstaticviewer and the > examples/CMakeLists.txt already limits the static build to just this > app so thats OK as it is. > > In the case of plugins, if you make the app static then you really > need to make the plugins static as there is potential collision about > what version of the OSG the plugins pull in vs what the application > pulls in. There is also the issue of each plugin need it's own static > linking of the core OSG libraries so sizes would go up through the > roof. For these two reasons I would have though that static core libs > + dynamic libs won't be sensible, if at all possible. > > Robert. > > > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
