Lib Not Found Msvcr90.dll Dependency Of
Savage Doherty
The redistributable package that contains version 9.0.21022.8 of msvcr90.dll and msvcp90.dll can be downloaded from the Microsoft website here. This will help PyInstaller to find the versions it wants and include them with the resulting executable.
I have a dll abc.dll.but when I open it in dependency walker,I depends on the MSVCR90.dll.I want to set the property of the project such type it should be independent of that dll.How it is possible.I am using vs2008.
Statically link to the CRT (/MT). That will remove the msvcr90.dll dependency (by basically including the CRT inside your dll). Note that if your dll uses other dlls, their dependencies might drag msvcr90.dll and friends in after all. In such cases, you'd better off using dynamic linking.
If you give the finished exe to someone else they will need to install the latest visual c runtime to run it. This will only work for release build AFAIK. Visual studio should install the required runtime both release and debug into your path. The project probably has an additional dependency accidently set for an incorrect version of the runtime.
I have an application that uses VISA32.dll. VISA32.dll has a dependency problem for MSVCR90.dll. I have some other steps to making the application work so I am not sure that it actually doesn't work. But it became evident using dependency walker that MSVCR90.dll is not found. It is actually required twice in fact, the second place bein another level down beneath VISA32.dll then beneath NIVISV32.dll. It is also not found there.
With WinSxS it is my understanding that it is more of a nogo by choice than a crash. It checks for the right version numbers and if they aren't found then it's nogo. I am aware that I can pick versions of the files myself from WinSxS and copy them to C:\Windows\system32 and this will force it to find those files without checking assembly versions.
And the second, even more confusing thing is that the msvcp90.dll depends on msvcr90.dll but the msvcr90.dll cannot be found!?! Hey, it's in the same winsxs-directory together with msvcm90.dll and msvcp90.dll!If I copy the right msvcr90.dll in the same directory as my dll it works! (But again, isn't that the situation we had in DllHell times? And shouldn't that msvc*.dll-copying should be over since we have manifests???)
I think this is the first version of shell plugin that was compiled with visual studio.
Can you download "Dependency walker" program and verify that you don't have some missing dll dependency. That is what your error is saying, and it also makes sense because this version was compiled with different compiler.
This is from nppshell_05:
Error: The Side-by-Side configuration information for "c:\program files (x86)\notepad++\NPPSHELL_05.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).
Error: At least one required implicit or forwarded dependency was not found.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
This is from nppshell_04:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
I found that I had to set the path variable to include the python version number.
In my case python installed in %appdata%
So the path has to include C:\Users\USERNAME\AppData\Local\Programs\Python\Python37-3
So it appears that a IVF dependency is not there still. Is there a runtime installer for IVF dependencies? Am I prohibited from distributing Debug releases? Is there any way to get more information about exactly why the app is failing when the CLL routine is called?
At first we were put off by IVF's separate debugger (I didn't understand that the VS debugger was perfectly adequate for almost everything we were doing). Benchmarking initially showed Absoft being faster than IVF for our app, but we are writing large binary file and found that if we set IVF BUFFERS to non-default value, performance is somewhat better then Absoft.
Message reads:
/ Error: The Side-by-Side configuration information in "c:\programme\pgadmin\1.12\PGADMIN3.EXE" contains errors.
Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung
neu installieren (14001).
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
/
I found the first two on my hard disc an copied them into the pgadmin directory which fixed the problem.
The other two were not present on this system.
After approaching the path problem as described in the other post, and failing to get a resolution, I started to explore more using process explorer, and this lead me down the path of realizing that QGis was in fact trying to load two separate copies from two different locations of the file 'msvcr90.dll'
After doing this, a little more poking about in process explorer, showed me that QGis was also loading 'msvcp100.dll' and 'msvcr100.dll' from it's own folder, and that one or both of these DLL's had static dependencies on the 'msvcr90.dll' file that was in my system32 folder.
Note: CoreFunctions.dll is one of the DLLs of our product. It is dependent on the Visual C runtime files (including msvcr90.dll) and msvcr90.dll is located in the subfolder Microsoft.VC90.CRT as described in this article. But still, msvcr90.dll is not found by the OS loader.
Different compiler versions used by maya:
Around the Corner Maya compiler versions (update)This is an update on previous posts for older versions which can be found here: Maya 2015, Maya 2014, Maya 2008 to 2013. Maya 2016 Windows 64bit Win7x64 Visual Studio 2012 Update 4 + Win 8 SDK .Net framework 4.5.1 Intel Composer XE 2015 Initial...
Error: "Could not load file or assembly XXXX.dll or one of its dependencies. The module was expected to contain an assembly manifest."
DLLs referenced by XXXX: msvcp90.dll,msvcr90.dll,myodbc5S.dll,myodbc5w.dll,myodbc5S.dll,myodbc5w.dll,dbcon16.dll,dbicu16.dll,dbicudt16.dll,dblgen16.dll,dblib16.dll,dbodbc16.dll,dbrsa16.dll,libodbcHDB.dll,msvcp100.dll,msvcp110.dll,msvcr100.dll,msvcr110.dll,sybcsi_core210.dll,sybcsi_openssl210.dll,sybcsi_profiler210.dll,sybcsi_propertiesconfig210.dll,sybcsi_rolecheck210.dll,sybdrvodb64.dll,dbcon16.dll,dbicu16.dll,dbicudt16.dll,dblgen16.dll,dblib16.dll,dbodbc16.dll,dbrsa16.dll,libodbcHDB32.dll,msvcp110.dll,msvcr110.dll,sybcsi_core210.dll,sybcsi_openssl210.dll,sybcsi_profiler210.dll,sybcsi_propertiesconfig210.dll,sybcsi_rolecheck210.dll,sybdrvodb.dll,libadonetHDB.dll,libSQLDBCHDB.dll,SybaseResources.dll,git2-75db289.dll,Microsoft.WITDataStore64.dll,dblgen16.dll,dbrsa16.dll,FmtOptions.dll,libsybskrb.dll,msvcp90.dll,msvcr90.dll,QP5.dll,ToadPro.dll,ToadProfilerLib.dll
This snippit of output shows 3 DLL's whose line ends with Error dll not found, after getting such a result, a little research online showed they are only are relevant for other versions of Windows and can safely be dismissed as a cause of the problem.
The two lines starting with ERROR: are of more interest. These two DLL's should have been loaded from the gtk-runtime directory, however for whatever reason they have been found and loaded from c:\windows\system . In this case removing/renaming those two DLL's in the windows directory allowed python to correctly import gtk, hence GRAMPS was then able to work.
What had happened in the above case, although the two DLL's were found in windows\system, the gtk-runtime could not work with them as they were from an older installation, and not the correct version for the current gtk installation.
In another example (below) you can see that some DLL's were found in other installation directories, this may or may not affect the ability of python to import gtk, it depends if the dll's in the other directories are compatible with what the gtk-runtime needs or not. In one case I had a perfectly working system, but it was picking up DLL's from other installations, in this case upgrading another program can suddenly break the gtk installation.
Prior to the manifest, DLLs were bound solely by the import list in the EXE/DLL, which gives the name of a DLL and a list of entry points to import. Manifests additionally say which version of the DLL to use. That there are two separate mechanisms involved in the CRT DLL resolution process should send a chill up your spine. Either the import list or the manifest can cause your program to fail to load, and the problem is that most people are only familiar with how to debug the import list, which leaves them dumbfounded when it's actually the manifest that's the problem. Remember that LNK4098 example I showed earlier? Well, after adding /NODEFAULTLIB:MSVCRTD, the executable's import list only shows MSVCRT.DLL, and all is good... except for the manifest:
Fast execution by parallelization: OpenMP and CUDA are supported.
- Multi-platform: Linux, OS X, and Windows are supported.
- Planar and toroid maps.
- Rectangular and hexagonal grids.
- Gaussian or bubble neighborhood functions.
- Visualization of maps, including those that were trained outside of Python.