I have seen you solved your problem. Just for information, Terry Welsh writes:
> Sorry about the incorrect subject line before. I hate it when I do that :( > >> But I'm not talking about that usage. I'm talking to set it just for >> your application. I have seen many commercial applications doing that ?a >> launcher script that sets LD_LIBRARY_PATH *in that shell* and then >> executes the process, so it uses the dynamic objects bundled with the >> application instead of system ones. >> >> > That's a good point; that's probably a safe way to use it. I tried > setting LD_LIBRARY_PATH=. and it makes it so ./osgPlugins-version is > searched but not . I haven't figured out why yet, but it must be some > detail inside of OSG. If you mean that you want to be able to load a plugin not found under a directory with the name 'osgPlugins-version', I can't think now of a way to do that with system tools, since OSG chains the name of the directory when loading it. There you should go the FindFileCallback route. > However, I'm still leaning toward solving this problem with internal > OSG functionality if possible since I want this app to be > cross-platform and Windows does not have a direct equivalent to > LD_LIBRARY_PATH. I'd rather use OSG behavior that is guaranteed to be > consistent across platforms. > On Windows, manifest stuff aside, you can just put your DLLs next to the executable and the OS will load them. This is also done by a lot of commercial software, bundling their own version of libraries. But if you just copy a plugin and you don't place it under osgPlugins-version, it won't load either. If I recall correctly, this was done on purpose in other to not to mix plugins coming from different versions of OSG on platforms where DLLs don't originally carry versioning information by default. -- Alberto _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
