Well done Jorge, It works :). And from I've read I think we should go this way. I recommend to apply this patch if Robert agree.
Cheers. 2013/3/25 Jorge Izquierdo Ciges <[email protected]> > Whooops wrong file, in the first file the return type was missing. > > > 2013/3/25 Jorge Izquierdo Ciges <[email protected]> > >> This patch seems to work in android and mimics the approach in Scene.cpp >> with a singleton. Check it out and comment. >> >> >> 2013/3/25 Jordi Torres <[email protected]> >> >>> Hi Jorge and Robert, >>> >>> I can confirm that the problem is in the static initialization in >>> Uniform.cpp. As far as I've readed in the android documentation they >>> recommend to go through the singleton initialization way, like you did at >>> Scene.cpp. I'll try to provide a patch this week using the same >>> approximation. >>> >>> Cheers. >>> >>> 2013/3/19 Jorge Izquierdo Ciges <[email protected]> >>> >>>> Robert sorry for the lateness i've been dragging in the Fallas here in >>>> Valencia and my head it's still spinning out. I checked what you told me >>>> and you were right it's not a static initialization order or at least >>>> doesn't happen in other distributions. Maybe it's something related to >>>> being a Native library loaded from Java or something done by the arm >>>> compiler. About the static initialization in Android there's not much data >>>> around the only tibdibts that are know to create great bugs are global >>>> static variables. >>>> >>>> Android can unload a library at any time. If you restart the process >>>> the global static variables are not initializated again. This issue is well >>>> known at the NDK Android circle and i've had to overcome those things by >>>> little hackings to ensure a full reload of libraries but that it's not the >>>> case here. This happens as soon as the library is loaded the first time and >>>> before the confirmation message of library fully loaded. >>>> >>>> I suppose that a similar solution to the one used in the changes in >>>> scene.cpp should work in Android for this bug. >>>> >>>> >>>> 2013/3/19 Robert Osfield <[email protected]> >>>> >>>>> Hi Jorge, >>>>> >>>>> I've been thinking about the static initialization problem and how we >>>>> might keep all the usage models/platforms happy. My current favored >>>>> approach would be to keep the static variables local to the static >>>>> singleton function (like how the Uniform.cpp code was) and have a >>>>> static proxy object in the global scope that invokes the singleton >>>>> function. This static proxy object would be there simply to avoid >>>>> issues with multi-threaded usage and potentially could be optionally >>>>> compiled in. >>>>> >>>>> I don't know specifically what the problem is under Android yet so >>>>> can't say whether this will actually fix the issue. >>>>> >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Jordi Torres Fabra >>> >>> gvSIG 3D blog >>> http://gvsig3d.blogspot.com >>> >>> >>> _______________________________________________ >>> 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 > > -- Jordi Torres Fabra gvSIG 3D blog http://gvsig3d.blogspot.com
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
