The situation:
I have a local sample project in a VS solution (one source file importing openCV headers, creating an empty image and displaying it).
I want to include any dependencies the project needs in the same folder, which I intend to git in a private repository. I don’t rally understand linking.
On my local machine I did the following:
Moved the .lib files and the include files to the solutions’ folder.
Configured the projects’ configuration properties:
-C/C++: Additional Include Directories
-Linker: Additional Library Directories and input (.lib files)
The project builds fine, but in debugging phase, the console throws some warnings, such as: > [ INFO:0] global C:\Users\DICAM39\Downloads\opencv-4.5.2\sources\modules\core\src\utils\plugin_loader.impl.hpp (67) cv::plugin::impl::DynamicLib::libraryLoad load opencv_core_parallel_openmp452_64d.dll => FAILED
After some searching I found out, that it has something to do with load-time linking vs run-time linking of the .dlls.
Anyways, on other machines the same solution does not work, because the .lib files seem to refer to the .dlls in the original output folder (from where the .libs where also copied); not present on any other but the main PC (where the original project files were).
My question:
How can I create a solution, which would work on any machine (with the same processor architecture and operating system of course)?
Should I just copy all the .dlls to the folder in which the executable from my source code will be generated? Seems like an odd and dirty method for doing it.
It would maybe.
Anyways, I’m now copying all the .dll-s to the build target directory using a Pre-Link Event. So more or less, my problem is solved. I will now test whether the thing works with different platforms and configurations and consider the problem solved.
Ok, so before linking I copy all of the DLLs from a directory into the target directory. It solved the all the errors in the release configuration. The building of the project is successful and the Local Windows Debugger does not write any warning into the console window.
However, in debug configuration the Local Windows Debugger is still complaining that it can’t find the required dll-s in their ORIGINAL location (not in the solution folder). Why would it even search for those DLLs in that location? Does Windows Debugger run from somewhere else?
You have to copy release and debug dll. That’s shorter way to copy all dll but after 20 VS project you will to copy about 20Gb… Add opencv to system path
Does the debugger give you a message specifying the location it is searching?
If your target location isn’t fixed and changes depending on debug or release the location will change.
In VS when debugging and using lots of different versions of libraries an alternative is to set the working directory (properties->Debugging->Working Directory) to the one containing the dll’s. That way you can change the dll’s location every time your run the program if you want. That said this won’t work if you need the working directory set to a specific location.!
You are right, I my target location depends on my configuration.
So if I understand you correctly, I have to change my working directory to be a directory with the appropriate .dll files.
How come then running Local Windows Debugger in release configuration did not write any of the warnings to the console window? I have a directory with the appropriate DLL files for debug and for release configuration separated in 2 folders. Pre-Link I copy all the DLL files from the appropriate directory to the TargetDirectory. copy "$(SolutionDir)\lib\opencv\bin\$(PlatformTarget)\$(Configuration)\*.*" "$(TargetDir)"
Ok, I checked the actual value of the macro in Release and in Debug mode. It seems, that regardless of the configuration, the Configuration macro reads Debug. The $(TargetDir) too. Is it normal?
I am not sure why you didn’t receive warnings but I would say that is unimportant. I am also not sure why you have Configuration as Debug in Release but I would guess you set that in the Configuration manager.
Anyway I would suggest as noted by @laurent.berger that copying the dll’s is the wrong approach when they are on the same machine that you are building on. Your initial question was regarding another machine. In that situation the only option is to copy the dll’s to that machine.
If you are using the same machine then the recommended way is to add to the user/system path and keep the dll’s in a single location. This can present a couple of problems
If you add to the system path then you may need to restart windows for the change to take effect.
If you add to the user path then you will need to restart visual studio.
Both these problems can lead users to believe that this approach has not worked.
For this reason and to avoid having to restart visual studio I recommended adding the directory containing the dll’s to the working directory. This allows you to change everything lib/headers and the location of the dll without having to restart visual studio.
The main reason I want to make everything using relative paths to the solution folder is the fact, that I want to make a git repository of that folder and make possible to the user on the other machine to build the code without changing anything else on their machine (adding path variables and such). So I have no intention to add paths to the system path.
I fixed the configuration manager, so my relative paths are generated correctly. However, the the problem in Debug using Local Windows Debugger still remains.
Let’s just ignore the fact, that I don’t have Tesseract correctly installed. Here are the differences between the two debugging console windows.
As you see, in debug configuration the functions can’t find their .dll files with the definitions despite having all the .dll files copied to the folder in which the built .exe file is before compilation.
Firstly I would not recommend distributing Debug as the Visual Studio redistributables will be a problem. That said I assume you are just using Debug as an example of a different solution configuration.
Therefore If it was me as a pure sanity test I would go to the target directory in cmd
i don’t think, any of the opencv_core_parallel_XXXX dlls exist on your (or my) machine.
this is a quite new, experimental feature:
it seems, you can override the builtin parallel framework, if you can supply such a dll at runtime. (don’t ask me, where the code for this is)
tl;dr:
you’re safe to ignore those warnings,
and maybe it should not be “info” but rather “debug” log level, there…
