Hi Roger, On 8/11/07, Roger James <[EMAIL PROTECTED]> wrote: > Please remember, that as I mentioned in my initial post, my comments were > limited to the windows platform only. Also my problem was that my application > was loading someone else's versions of the plugins from where someone else > had put them, not from where I had put my versions. That other installation > could date back to the dawn of osg time, before the time that the osg plugins > directory was invented.
This is why from 2.0 onwards we now use the osgPlugins-version directory, this should avoid runtime mixing of versions. > Whilst the behaviour of my installation program is under my control, the > behaviour of other peoples is not. So the way things are at the moment I run > the risk of things crashing horribly on random machines. Personally I happy > to run with my private fix to specifically null out the library search path > at application start time, and leave things as they are. However I think many > other developers of OSG applications for the windows platform will fall foul > of this issue. > > Also if there is to be a "rule" that osg plugins must reside in a > specifically named sub-directory then this needs to be clearly documented and > the code modified so that a plugin load cannot find them anywhere else. This > is not the case at the moment. I am far from convinced that this is the > correct approach, but I can live with it provided that at least the bit about > the code not be able to find plugins anywhere else is implemented. Once this > flurry has died down I will submit a patch to implement it if required :-) We are already basically there, the only thing we need to tighten up on is changing the plugin code so it only ever searches for osgPlugins-version/osgdb_x rather than checking for osgdb_x first then osgPlugins-version. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
