Package osg plugins can't be found when running executable

[HarryDC]

This is under windows, VS 2017. Osg (OpenSceneGraph) and the plugins were successfully built, the osg dlls are under /bin, the plugins under /tools/osg, but while the main osg.dll can is found correctly when running out of visual studio the plugins cannot be found.

-- Edit
We are using cmake on a midsize codebase, amongst others OSG is a dependency. We have been building dependencies "by hand" and now trying out vcpkg, osg is a bit of a problem.

With VCPKG_APPLOCAL_DEPS set to true, all the libraries that are linked are copied to the local directory wich is fine, but the plugins are not explicitly linked, and are situated in the tools under osg directory (as suggested in this post #834). In a "normal" configuration the dlls and plugins would be on the path, I haven't seen any documentation on how this should be handled using a vcpkg installation. Should tools be put on the path ? An extra copy outside of vcpkg ? Or can these files be marked as "need to copy" without explicitly linking them via add_library() in cmake.

[icedream2linxi]

The code for applocal.ps1 needs to be modified to enable automatic copying of osg plugins. For example, the implementation of Qt5 and OpenNI2.

需要修改 applocal.ps1 的代码才能实现自动复制 osg 的插件。例如，Qt5 和 OpenNI2 的实现。

https://github.com/Microsoft/vcpkg/blob/e9f36a0e2734d9130217548387ad87f7f494d47d/scripts/buildsystems/msbuild/applocal.ps1#L65-L66

https://github.com/Microsoft/vcpkg/blob/e9f36a0e2734d9130217548387ad87f7f494d47d/scripts/buildsystems/msbuild/applocal.ps1#L85-L94

[martin-s]

This is already coming from a workaround. Initially, the osg-plugins should be located in the bin folder. As vcpkg cannot handle the missing exports yet (see #3889), the libraries are copied to the tools folder to circumvent the post-checks.

[HarryDC]

@martin-s Well maybe I haven't configure something correctly, I can see that they are being copied to the tools folder, but they still can't be found. Out of the box on a project that used a normal osg installation it doesn't work. What is the suggested setup ?

[martin-s]

The point was not to introduce another workaround by polluting other build scripts. The copy of OSG libs is not done by magic; it's done because it's written in the port file which is the "original" workaround. Hence, take an action on your local port file would be my suggested solution.
I'm strongly against adding another if/else part to a, which seems to me, generic build script.

[LilyWangL]

Hi @HarryDC, thanks for posting this issue! Openscenegraph has been upgrade to version 3.6.3, does this issue still occur?

[HarryDC]

I don't have an environment to test this anymore, looking at the portfile i'd say the issue is still there, the plugin dlls get copied into a directory that isn't on the path

[betsch85]

Hi @HarryDC, thanks for posting this issue! Openscenegraph has been upgrade to version 3.6.3, does this issue still occur?

I've just built osg[collada,core] and I can't import dae-files. No env vars were created during the build process and I don't know where to copy the files from the tools/ dir. I've basically tried everything.
I have:

• installed\x64-windows\bin with the osg dlls
• installed\x64-windows\lib with the osg libs
• installed\x64-windows\tools\osg\osgPlugins-3.6.3 with all the plugins (including osgdb_dae.dll)
  and the same for debug
• installed\x64-windows\debug\bin with the osg dlls
• installed\x64-windows\debug\lib with the osg libs
• installed\x64-windows\debug\tools\osg\osgPlugins-3.6.3 with all the plugins (including osgdb_daed.dll)

I've copied osg\osgPlugins-3.6.3 to bin, I've copied osgPlugins-3.6.3 to bin, and did the same relative to the .exe I'm running.
Always the same result: Could not find plugin to read objects from file

[calumr]

The osgdb_dae.dll is probably missing some dependencies? I use this Dependencies tool to check them:

https://github.com/lucasg/Dependencies/releases

In my build I have a collada-dom2.5-dp-vc140-mt.dll, as well as it's dependencies (uriparser, zlib1, boost filesystem & libxml2).

[betsch85]

The osgdb_dae.dll is probably missing some dependencies? I use this Dependencies tool to check them:

https://github.com/lucasg/Dependencies/releases

In my build I have a collada-dom2.5-dp-vc140-mt.dll, as well as it's dependencies (uriparser, zlib1, boost filesystem & libxml2).

I checked that. osg_dae.dll itself has dependency on osgAnimation and osgSim, I added those. collada-dom2.5-dp-vc140-mt.dll has dependency on uriparser, zlib1, boost::fs and libxml2, added those as well. Dependencies isn't showing anything missing but it's still not working. My application doesn't have a dependency on osg_dae.dll, I think it's supposed to load that at run time?!

[JERRYZFC]

set env OSG_NOTIFY_LEVEL to DEBUG
and you can see info like below

then search your local disk and put the dir to the address above

[JackBoosY]

For ports that contain plugins, we should write a script that replicates the plugin for them to inject this behavior during the installation of dependencies.