LabVIEW
tbb.dll entrypoint not found
tbb.dll (and it's accompagning DLLs) is a DLL that gets normally installed in the system32 directory. As such you should avoid to have it anywhere else on your system. Now it seems tbb gets actually installed by several LabVIEW components and so is already loaded in recent LabVIEW versions when LabVIEW gets started.
Now you might get in a number of troubles here. First if you reference the DLL by path in a Call Library Node Windows will load the DLL as so called SxS (Side by Side) DLL into memory. This is to prevent troubles with different components expecting different versions of the DLL, yet it opens up a big can of worms too. Most DLLs getting installed in system32 do so because they maintain global state and other things internally that gets totally messed up when you load the DLL again from a different location.
Another problem however can be version differences in the DLL. The standard version installed by whatever software makes use of it, may be older than what your own software needs. In that case you have to install the newer version of the library in your system to replace the older version, not put it somewhere else to be loaded in parallel. And keep your fingers crossed, that the library has not introduced incompatible chances between versions, as that would simply make whatever other software has used it before, fail now. Yes it's all DLL hell, but SxS would not be the solution for it either, just a different way of getting roasted in DLL hell.
@Bublina wrote:
If I copy the expected DLL in the system32 folder, it solves the problem and the labview code compiles, but it is very radical solution and might cause the rest of involved programs to stop working.
When I have some extra time, I will explore the problem properly and contact the NI support directly.
You shouldn't copy the DLLs into the system32 folder by yourself. There has to be an installer somehow by whatever software makes use of this library and that installer should take care about checking for version difference and installing the new version where it should be.
Sorry to bump this old thread, but I have a related question.
I tried to decompose dependencies of the problematic DLL, and dependancy walker shows calls to wrong library.
Problem is, that the call comes from a library allready build.
If someone using MSVC OpenCV build knows how to force a build without this dependency problem, please shed some light.
I used some standard average joe tutorial with c-make.
You can't force Windows to load a different DLL with the same name in an application that is already using a DLL, unless you use SxS which requires both DLLs to contain a manifest resource that specifies its version and compatibility and install the versions into the SxS directory or as private copy into your application directory. All applications and shared libraries using that DLL need to contain an according manifest resource too.
Since Intel chose to normally have developers install tbb.dll and related into System directory, SxS is not an option. You would not only have to install the library that LabVIEW is using into SxS and relink it to contain the necessary manifest resource but also add a manifest resource to LabVIEW itself, or whatever dependant DLL links to tbb.dll.
The only feasable choice you have is to find out what version is already installed, and find a proper installer for the version you need, and install that over the already installed version if it is newer. And then keep your fingers crossed that Intel didn't introduce binary incompatible chances to the new DLL. And of course when you distribute your OpenCV based library/toolkit or whatever, you have to make sure any user is installing that version of the tbb.dll distribution too. That installer needs to check for an already installed tbb.dll check it's version and if older replace it by the new version, making whatever registry changes there need to be.
