Hi Robert,

On Thu, Dec 18, 2008 at 10:51 AM, Robert Osfield
<[email protected]> wrote:
> Hi Mattias,
>
> I can't think of any reason why multi-threaded would be any different
> than single thread when running with a static build.  I'll do a static
> build here and see if I see any issue when multi-threading.  I think
> to resolve this type of problem we'll need to roll out testing to the
> wider community to see what a range of machine, hardware, drivers and
> OS's think of the static build.

ok. I may be setting up a dell xps laptop over the holidays. If so
I'll try a static build on it.

>
> Do you have to make any mods to the OSG to get things running with static 
> build?

no. no mods . Built fine.

Mattias
>
> Robert.
>
> On Thu, Dec 18, 2008 at 12:30 AM, Mattias Helsing <[email protected]> wrote:
>> 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
>>
> _______________________________________________
> 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

Reply via email to