I've setup Ogre and dependencies on my PC, and downloaded some Ogre applications. When I launch my new exe file of the project I just downloaded it generates the following error:
05:37:59: Loading library C:/OgreSDK_vc9_v1-7-1/bin/debug\RenderSystem_Direct3D9_d
05:37:59: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library C :/OgreSDK_vc9_v1-7-1/bin/debug\RenderSystem_Direct3D9_d. System Error: The specified module could not be found.
in DynLib::load at ..\..\..\..\OgreMain\src\OgreDynLib.cpp (line 91)
Any help would be appreciated.
Thanks in advance.
Upon creation of the central Ogre3D class Ogre::Root, you need to pass the name of a *.CFG file that contains all to be loaded Ogre plugins, such as the above mentioned D3D9 Render System.
That file needs to be next to your *.EXE by default and should look like this (in a minimal form where only the D3D9 Render System is loaded and the matching DLL file resides next to this CFG file):
# Defines plugins to load
# Define plugin folder
PluginFolder=.
# Define plugins
Plugin=RenderSystem_Direct3D9
For more information, have a look at this section in the Ogre3D tutorial 1
This took me a while until I figured it out. The dll (RenderSystem_Direct3D9_d) is missed because you didn't build it - it's the project with the same name (RenderSystem_Direct3D9) in the OGRE.sln
I'm using OGRE 2.1, so the dll I missing is RenderSystem_Direct3D11_d.dll instead of RenderSystem_Direct3D9_d.dll like yours, but the fix is similar, just build that dll's project, like the image below.
Anyway, as a beginner, to avoid any trouble, just hit F6 to build whole solution.
Related
I am experimenting with OpenVINO APIs and below is the sample code snippet:
plugin = InferenceEngine::PluginDispatcher(<params>).getPluginByDevice("CPU");
However, I get the below error:
Cannot find plugin to use :Tried load plugin : MKLDNNPlugin, error: Plugin MKLDNNPlugin cannot be loaded: cannot load plugin: MKLDNNPlugin from /opt/intel/openvino_2019.3.376/inference_engine/lib/intel64: Cannot load library '/opt/intel/openvino_2019.3.376/inference_engine/lib/intel64/libMKLDNNPlugin.so': libmkl_tiny_tbb.so: cannot open shared object file: No such file or directory
I looked for the above missing library and it actually exists:
$ ls /opt/intel/openvino_2019.3.376/inference_engine/external/mkltiny_lnx/lib/
libmkl_tiny_tbb.so
It looks like some internal dependency is not resolved by inference engine lib/plugin. Could anyone help figure out why it doesn't work?
Add/Update this path
/opt/intel/openvino_2019.3.376/inference_engine/external/mkltiny_lnx/lib/
libmkl_tiny_tbb.so
into
LD_LIBRARY_PATH
Run a script setupvars.sh before you run your program. The script resolves all dependencies needed for running OpenVINO applications.
The script located in <openvino-install-dir>/bin/setupvars.sh
I use boost::dll for loading libraries at runtime.
With the following code, I'm able to load a DLL even when it's in a different folder than the one with the executable:
auto creator = boost::dll::import_alias<pluginapi_create_t>(fileName, "createPlugin", boost::dll::load_mode::append_decorations);
But I've got a problem when a DLL has other dependencies. This is an example of my folder structure:
Main Folder
|
|-program.exe
|
|-pluginsfolder
|
|-plugin1.dll
|-plugin2.dll
|-dependency.dll
If I load plugin1.dll (which has no other dependencies), it works.
If I load plugin2.dll, that requires dependency.dll, it doesn't work.
I suppose I could put all the DLLs in the same folder, and everything will begin to work again. But I'd like to keep plugins in separate folders because I want other users to be able to load plugins from their respective folders.
How can I load plugins with dependencies regardless their position in the filesystem?
I've found the solution, thanks to Richard comments.
This is the command:
auto creator = boost::dll::import_alias<pluginapi_create_t>(fileName, "createPlugin", boost::dll::load_mode::append_decorations | boost::dll::load_mode::load_with_altered_search_path);
I've added the boost::dll::load_mode::load_with_altered_search_path flag when loading, while searching how to use the corresponding LOAD_WITH_ALTERED_SEARCH_PATH using by windows natively.
I have followed the official guide for setting up OpenCv in codeblocks.I did everything as in the guide.I succeded to compile one code of the samples of opencv but when I run I have an error that some .dll is missing.More precisely this is the error:The application can't start because libopencv_core242.dll is missing from your computer..Try reinstaling the application...The awkward thing is that this static library is present in the bin folder under build->x64->mingw->bin..
Any help would be appreciated.
Try to copy the dll into the folder containing the executable.
For a "cleaner" solution, it has been answered here (with libgcc) : The program can't start because libgcc_s_dw2-1.dll is missing
Basically, either you copy the dll containing folder into the PATH ENV, or you can try to link with the statically.
I have created a gstreamer plugin with an element inside that would generate some data when put in a pipeline (by following the GStreamer Plugin Writer's Guide).
My problem is that I cannot load my plugin in a test application. When I call gst_element_factory_make("myextractor", NULL) the result is always NULL.
More data (I'm not sure this is related):
When I run gst-inspect on my dll I get incomplete output (output generated using cygwin):
beq11049#beqleuleu1nb028 /cygdrive/c/work
$ /cygdrive/c/OSSBuild/GStreamer/v0.10.6/bin/gst-inspect.exe MyProject/Release/gstxyzlibrary.dll
Plugin Details:
Name: myextractor
Description: XYZ Library
Filename: MyProject/Release/gstxyzlibrary.dll
Version: 1.0
License: LGPL
Source module: myextractor
Binary package: MyProject
Origin URL: http://www.example.com/
myextractor: XYZExtractor
1 features:
+-- 1 elements
If I compare this with the avisubtitle addon (from the GStreamer Good Plug-ins package) I get a lot less information for mine.
For example, my plugin says:
1 features:
+-- 1 elements
The avisubtitle plugin says (generated using $ /cygdrive/c/OSSBuild/GStreamer/v0.10.6/bin/gst-inspect.exe avisubtitle):
GObject
+----GstObject
+----GstElement
+----GstAviSubtitle
My question: I need advice on how to debug this / determine what I am missing (enabling debugging output, settings and paths to check and so on). My test code (the call to gst_element_factory_make) is written in a Songbird adon, but I get the same results if I put my code in a separate executable.
It might be because the loader can't find your plugin, you should check that your plugin is in the shared library path:
Make sure you've set the LD_LIBRARY_PATH environment variable to the directory containing your compiled plugin.
In cygwin, add this to your .profile, or run it before you run your program:
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/cygdrive/c/path/to/your/plugin/"
You could also use the -L linker option to specify a search path at compile time.
I am not sure how to answer your question, because there might be several things missing. I think about unresolved symbol depedencies (although unlikely, since you can actually inspect your plugin) or wrong registration, somehow (it's also difficult to get it wrong), perhaps issue with songbird or windows that I ignore.
However, I just want to clear out one thing: GStreamer has "plug-ins" (aka dynamically loadable library) that can contain one or more elements. When you gst-introspect the plug-in or the element, you get different outputs! In the case of "avisubtitle", it's an element, and you can read the class hierarchy. If you introspect the plugin (or the library) "avi" or "/usr/lib/gstreamer-0.10/libgstavi.so" (on Unixes), you get the list of elements it contains and some common properties (version, project etc..).
For example, gst-introspect XYZ (XYZ a library or a path to a library) is different than gst-introspect XYZ (XYZ the name of the element in the XYZ library)
Perhaps that will helps you. good luck! Oh, and errors/warning can be displayed with the environment variable GST_DEBUG=*:2
I'm including python.h in my Visual C++ DLL file project which causes an implicit linking with python25.dll. However, I want to load a specific python25.dll (several can be present on the computer), so I created a very simple manifest file named test.manifest:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<file name="python25.dll" />
</assembly>
And I'm merging it with the automatically embedded manifest file generated by Visual Studio thanks to:
Configuration Properties -> Manifest Tool -> Input and Output -> Additional Manifest Files
-->$(ProjectDir)\src\test.manifest
python25.dll is now loaded twice: the one requested by the manifest, and the one that Windows should find through its search order.
Screendump of Process Explorer http://dl.dropbox.com/u/3545118/python25_dll.png
Why is that happening and how can I just load the DLL file pointed by the manifest?
After exhaustive battle with WinSxS and DLL redirection, here's my advice for you:
Some background
Various things can cause a DLL file to be loaded under Windows:
Explicit linking (LoadLibrary) -- the loader uses the current activation context of the running EXE file. This is intuitive.
Implicit linking ("load time linkage", the "auto" ones) -- the loader uses the default activation context of the depending DLL file. If A.exe depends on B.dll depends on C.dll (all implicit linkage), the loader will use B.dll's activation context when loading C.dll. IIRC, it means if B's DllMain loads C.dll, it can be using B.dll's activation context -- most of the time it means the system-wide default activation context. So you get your Python DLL from %SystemRoot%.
COM (CoCreateInstance) -- this is the nasty one. Extremely subtle. It turns out the loader can look up the full path of a DLL file from the registry using COM (under HKCR\CLSID). LoadLibrary will not do any searching if the user gives it a full path, so the activation context can't affect the DLL file resolution. Those can be redirected with the comClass element and friends, see [reference][msdn_assembly_ref].
Even though you have the correct manifest, sometimes someone can still change the activation context at run time using the Activation Context API. If this is the case, there is usually not much you can do about it (see the ultimate solution below); this is just here for completeness. If you want to find out who is messing with the activation context, WinDbg bp kernel32!ActivateActCtx.
Now on to finding the culprit
The easiest way to find out what causes a DLL file to load is to use Process Monitor. You can watch for "Path containing python25.dll" or "Detail containing python25.dll" (for COM lookups). Double clicking an entry will actually show you a stack trace (you need to set the symbol search paths first, and also set Microsoft's PDB server). This should be enough for most of your needs.
Sometimes the stack trace obtained from above could be spawned from a new thread. For this purpose you need WinDbg. That can be another topic, but suffice to say you can sxe ld python25 and look at what other threads are doing (!findstack MyExeModuleName or ~*k) that causes a DLL file to load.
Real world solution
Instead of fiddling with this WinSxS thing, try hooking LoadLibraryW using Mhook or EasyHook. You can just totally replace that call with your custom logic. You can finish this before lunch and find the meaning of life again.
[msdn_assembly_ref]: Assembly Manifests
I made some progress for the understanding of the issue.
First let me clarify the scenario:
I'm building a DLL file that both embeds and extends Python, using the Python C API and Boost.Python.
Thus, I'm providing a python25.dll in the same folder as my DLL file, as well as a boost_python-vc90-mt-1_39.dll.
Then I have an EXE file which is a demo to show how to link to my DLL file: this EXE file doesn't have to be in the same folder as my DLL file, as long as the DLL file can be found in the PATH (I'm assuming that the end user may or may not put it in the same folder).
Then, when running the EXE file, the current directory is not the one containing python25.dll, and that's why the search order is used and some other python25.dll can be found before mine.
Now I figured out that the manifest technique was the good approach: I managed to redirect the loading to "my" python25.dll.
The problem is that this is the Boost DLL file boost_python-vc90-mt-1_39.dll that's responsible for the "double" loading!
If I don't load this one, then python25.dll is correctly redirected. Now I somehow have to figure out how to tell the Boost DLL file not to load another python25.dll...
Dependency Walker is usually the best tool for resolving this kind of problem. I'm not too sure how well it handles manifests though...
Where in this entangled mess is the actual process executable file?
Two possibilities come to mind:
You are writing a Python extension DLL file. So the Python process is loading your DLL file, and it would already have its own python25.dll dependency.
The EXE file loading your DLL file is being built with header files and libraries provided by the DLL file project. So it is inheriting the #pragma comment(lib,"python25.lib") from your header file and as a result is loading the DLL file itself.
My problem with the second scenario is, I'd expect the EXE file, and your DLL file, to be in the same folder in the case that the EXE file is implicitly loading your DLL file. In which case the EXE file, your DLL file and the python25.dll are all already in the same folder. Why then would the system32 version ever be loaded? The search order for implicitly loaded DLL files is always in the application EXE file's folder.
So the actual interesting question implicit in your query is: How is the system32 python26.dll being loaded at all?
Recently, I hit a very similar problem:
My application embedding Python loads the python32.dll from a known location, that is a side-by-side assembly (WinSxS) with Python.manifest
Attempt to import tkinter inside the embedded Python interpreter caused second loading of the very same python32.dll, but under a different non-default address.
The initialisation function of tkinter module (specifically, _tkinter.pyd) was failing because to invalid Python interpreter thread state (_PyThreadState_Current == NULL). Obviously, Py_Initialize() was never called for the second Python interpreter loaded from the duplicate python32.dll.
Why was the python32.dll loaded twice? As I explained in my post on python-capi, this was caused by the fact the application was loading python32.dll from WinSxS, but _tkinter.pyd did not recognise the assembly, so python32.dll was loaded using the regular DLL search path.
The Python.manifest + python32.dll assembly was recognised by the DLL loading machinery as a different module (under different activation context), than the python32.dll requested by _tkinter.pyd.
Removing the reference to Python.manifest from the application embedding Python and allowing the DLL search path to look for the DLLs solved the problem.