Here's the problem I got for Qt Application(Qt4\Qt5) calling Dlls from Fortran(CVF\IVF).
Qt4+Dll(CVF)+WinXp
It works fine in my PC both in QtCreator and as solo.
not working in other's (xp or win7/8)
the error is "dll not loaded" ( .isLoaded() false message)
then my PC's dead, got new one and immigrated to Qt5 with IVF.
But still the problem:
Qt5+Dll(IVF with complier_platform win32)+Win8
It works fine in my PC both in QtCreator and as solo
not working in other's (xp or win7/8)
the error is "dll not loaded" ( .isLoaded() false message)
Well, after trying them from various PCs:
I suppose it's not the platform problem(32bit or 64)
I am sure the dll path is correct when calling
Qt calling codes are
if(stlDll.load()){
myfun fun1 = (myfun)stlDll.resolve("STLDLL");
if ( fun1 ){
fun1(fileName_For90);
}
}
else
QMessageBox::information(NULL, "File Missing",tr("dll not loaded, the Directory is ")+dllPath, QMessageBox::Ok);
the error is always "dll not loaded", however that's the very right dllPath where I can find the dll with eyeballs but the Qt Applicaiton can not.
Fortran dll compiling codes are :
!DEC$ ATTRIBUTES DLLEXPORT,ALIAS::stlDLL
Typically DLL's compiled with Intel Fortran are dynamically linked to the Intel Fortran (and underlying Microsoft C++) runtime DLL's. Are your Fortran DLL's compiled and linked that way?
If so, you need to have the Intel Fortran runtime DLL's (and the underlying Microsoft C++ runtime DLL's) installed on the target machine.
You can get installation packages for the Intel Fortran runtime DLL's from the Intel website in the same manner that you acquire downloads of the compiler (or see here). You can get installation packages for the Microsoft C++ runtime libraries by searching the Microsoft website (they are Visual Studio version and service pack specific). Alternatively, merge modules and installation exe's for the runtimes may have been installed on your machine as part of the Intel Fortran and Visual Studio installations.
Related
When compiling my Rust app in Windows 10, it is linked against ucrtbase.dll; however, this dll does not exist on some editions of Windows Server 2008 R2 Datacenter, making my app impossible to execute.
I tried setting -Ctarget-feature=+crt-static as found here, but it did not do anything; ldd app.exe still shows this dll.
Is there a way of removing the dependency on this dll?
If your Rust app does not depend on C libraries that specifically require the MSVC toolchain, you can build it for the x86_64-pc-windows-gnu (or i686-pc-windows-gnu, to build for 32-bit CPUs) target instead. This target links to DLLs that are available in all Windows versions.
For more information about the different Windows ABIs, you can check out this documentation page.
I am not very experienced. Just trying to make some changes to source code that someone else wrote.
I had to add a reference to a .dll to get it to work in "Release" mode. However when I try to get it to work in Debug, it does not work. (assembly reference not loaded).
Help?
It looks like the Chillkat dot net is a actually a mixed mode assembly and it's quiet possible that you need to have the appropriate c runtime as well. This exception and a way to fix this is documented here
Hope this helps.
Typically I get this error when the executable is x86 and the dll it's referencing is x64. Check your build configurations to make sure it's targeting the correct platform.
In VS2013 go to Build -> Configuration Manager. There should be a drop down in the top left of the new window which contains the different build modes. Compare Debug to Release.
BadImageFormatException is one exception thrown from the execution engine when you are trying to load one assembly compiled for a specific platform in another platform.
Example A
- project A, compiled as X86
- project B, compiled as X86
- executable, compiled in X86
all work fine in x86 machine and x64 operating system
Example B
- project A, compiled as X86
- project B, compiled as X86
- executable, compiled in AnyCPU
all work fine in x86 operating system
this throw exception in x64 OS (executable is in AnyCPU so it's run on x64 engine, so can't load x86 dll's)
Example C
- project A, compiled as AnyCPU
- project B, compiled as x86
- executable, compiled in AnyCPU
all work fine in x86 operating system
this throw exception in x64 OS (executable is in AnyCPU so it's run on x64 engine, so can't load x86 dll's)
Example D
- project A, compiled as AnyCPU
- project B, compiled as x86
- executable, compiled in x86
all work fine in x86 operating system
all work fine in x64 operating system
the exe is compiled specifically for x86 platform, so also in x64 machine run under x86 mode.
Conclusion
Visual studio run projects in OS configuration, so in debug mode if you don't have a specific x86 configuration for starting project and try to execute an x86 referenced dll it will fail
I have a problem running my application on other machines.
I am developing with Visual Studio 2008 in a Win7 x64 machine.
The solution contains several C# projects (the main application is written in C#, all others are library projects) and two c++/CLI libraries. The C++ libraries are Win32 and all C# projects are set to x86 target processor. No third party libraries used. Framework used is v3.5.
The application builds and runs fine on my machine.
I copied the whole "bin\release" folder to a Win7 x86 machine and it ran fine, too.
But when I tried on a XP x86 system, it did not start. No error message, not even showing up shortly in the task manager. The XP system has all updates installed, all available .NET frameworks installed and all Visual Studio Runtimes installed.
I checked with DependencyWalker and the only missing dlls are "IEShim.dll" and "wer.dll" which are only for Vista or higher.
I tried another of my applications that's not using C++ libraries and they work fine. So I guess I am doing something wrong deploying the C++ dlls.
Registering the C++ dlls with "regsvr32" failed with a "DllEntryPoint" not found message. Registering with "regasm" was successful, but had no effect.
What is it that I am missing?
Well, seems like I was a bit hasty stating "no third party components".
Actually it was the SQL Server Compact who was missing its runtime.
I have a c++/cli dll that I load at runtime and which works great in debug mode. If I try and load the dll in release mode it fails to load stating that one or more dependencies are missing. If I run depends against it I am missing MSVCR90.DLL from MSVCM90.DLL. If I check the debug version of the dll it also has the missing dependency, but against the debug (D) version.
I have made sure debug/release embed the manifest file. I read something about there being issues with the app loading the dll being build as Any CPU and the dll being built as x86, but I don't see how to set them both to x86.
I am using VS2010.
Anyway, I've been messing around for a while now and have no idea what is wrong. I'm sure someone out there knows what is going on. Let me know if I need to include additional info.
alt text http://www.freeimagehosting.net/uploads/fb31c0e256.png
UPDATE:
This ended up being the resolution to my problem: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/07794679-159b-4363-ae94-a68fe258d827
MSVCR90 is the runtime for Visual Studio 2008. If you are running your application on your development PC, then you should have the debug and release runtimes installed (as part of Visual Studio) but it is possible something has gone awry with your install, or that VS2010 doesn't actually include the older runtimes. If you're trying to run the Release on a different PC, then it just needs the runtime installed.
Either way, you may be able to fix it by installing the Visual Studio 2008 redistributable - but make sure you get the right download for your PC (x86 or x64).
In previous versions of VS, you needed the runtime for the version you were compiling with, so if VS2010 follows this precedent you'd need MSVCR100, not MSVCR90 - which suggests that you may not have recompiled the dll with VS2010 - doing so may be another approach to get it running on your PC (using the redist that is in your VS2010 install) but beware that you will still need other users to install the appropriate (VS2010) redistributable on their PC.
As for "Any CPU" versus "x86", this is a problem only on a 64-bit computer. On those systems a 64-bit application can't link dynamically to 32-bit dlls. If you compile your application as "Any CPU" it will be JIT compiled to be 64-bit on an 64-bit OS, so will crash if it tries to call any 32-bit dlls directly. THe solution is to build the application targeting "x86" as that forces the JIT compiler to generate 32-bit code (even on a 64-bit machine) and thus ensures compatibility with the dll you wish to call. If the DLL is a managed assembly, then you can use Any CPU on both the app an dll as they will both be JITted to the same format.
It happened to me something similar running a website in Vistual Studio 2012, after migrating from Visual Studio 2010. The error message was saying that MSVCR90.DLL was missing. The solution was:
1) Delete the folder _bindeployable located at the project path.
2) Rebuild.
I hope it helps.
Have GHC 6.8.3 and wxHaskell-0.10.3 on a Windows XP computer. Installed both as binary distributions, not by building from sources. Built a sample with the following command:
ghc --make Paint.hs
It works on that same computer it was built on (with GHC and wxHaskell installed), but fails if transferred to another one (with neither of them installed). It throws an "Application error" box with "The application failed to initialize properly (0xc0150002). Click OK to terminate the program."
The only non-system dll it wanted was wxc-msw2.6.4-0.10.3.dll, which I copied to it's folder.
What might be the reason?
The error comes from dependencies that are mentioned in the manifests of DLL's (presumably the third-party ones with wxHaskell) that your system is expecting to find installed in places such as WinSxS and SoftwareDistribution in your Windows directory. I am guessing the wxHaskell installation puts the files there.
You may be able to find what files the program is looking for by looking in the event viewer on the failed machine. You may even be able to fix them by moving the files from a working machine, However, VC++ 2005 runtimes are the most likely, as suggested - the wxHaskell troubleshooter suggests you try the VC++ 2005 service pack 1 redistributables:
http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en
My guess is, you want to install the VC++ runtime redistributable files onto the target computer. The redistributable files for applications built with visual studio 2005 are available from here:
http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
Datapoint: Works for me on an XP sp2 box.