Robert,
I have come across an issue with the current implementation of
osgDB::appendPlatformSpecificLibraryFilePaths on Windows platforms.
It is common practice on windows to place copies of the supporting dlls that
your program loads in the same directory as the executable. The standard
Roger,
I have run into the exact same problem with a customer install. Thanks for
submitting your workaround!
Justin
On Friday 10 August 2007 04:23:41 Roger James wrote:
> Robert,
>
>
>
> I have come across an issue with the current implementation of
> osgDB::appendPlatformSpecificLibraryFileP
Hello,
> My suggestion is, first let the operating system search for the shared
> library, only after that OSG should search for it, probably some OSG
> specific library search environmental variable, something like
> OSG_PLUGIN_PATH.
While I have not had problems with the current behaviour as so
On 8/10/07, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > My suggestion is, first let the operating system search for the shared
> > library, only after that OSG should search for it, probably some OSG
> > specific library search environmental variable, something like
> > OSG_PLUGIN
On 8/10/07, Orhun Birsoy <[EMAIL PROTECTED]> wrote:
> > No I disagree, if you are setting OSG paths explictly its because you
> > have something specific in mind - these should come before the OS
> > directories otherwise you'd never be able to have a localised OSG
> > install.
> >
>
> But dependin
> No I disagree, if you are setting OSG paths explictly its because you
> have something specific in mind - these should come before the OS
> directories otherwise you'd never be able to have a localised OSG
> install.
>
But depending on LD_LIBRARY_PATH to do that is not the way to do it.
This art
Thanks for bringing this up. It almost the same under linux as well.
It adds the paths in LD_LIBRARY_PATH to the filename and even worse it
also adds "./" to the filename. Especially the last one causes the
rpath linker option not to work, which is IMO the correct way to
specify shared library sear
>
> I think you're heading off on a bit too much of one variable war path.
> The OSG doesn't just depend upon LD_LIBRARY_PATH, oggDB::Registry
> sets up platform specific paths which include LD_LIBRARY_PATH, these
> are the defaults.
OK. I didn't know there was a variable war path as well :).
I'
On 8/10/07, Orhun Birsoy <[EMAIL PROTECTED]> wrote:
> I'll first ask a question. LD_LIBRARY_PATH (DYLD_LIBRARY_PATH, PATH)
> is already being used by the operating system to search for the
> library. What I don't understand why OSG needs to append these to the
> filename and do the search itself? D
>
> As J-S explained, the OSG is using this path list to look for plugins,
> and these plugins will be nested in a osgPlugins-version directory,
> the plugin won't be in the directly in the system directories or ones
> pointed to directly by *LD_LIBRARY_PATH.
>
I'll say this and won't iterate this
Hi Orhun,
On 8/11/07, Orhun Birsoy <[EMAIL PROTECTED]> wrote:
> >
> > As J-S explained, the OSG is using this path list to look for plugins,
> > and these plugins will be nested in a osgPlugins-version directory,
> > the plugin won't be in the directly in the system directories or ones
> > pointed
Hi Guys,
To the Registry::createLibraryNameForExtension(..) I have gone ahead
added the insertion of osgPlugins-version/ in front of plugin names
for all platforms except OSX.
This change will work to ensure that correct version of the plugins is
picked up at runtime.
Please not if you are settin
12 matches
Mail list logo
