Hi Robert, and thanks for the explanations. It all makes sense.
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
