I have a qt application which was in qt4.7 and I ported it to qt5.0. It is working fine if it is run from a PC where qt5 is installed. But it is not running or not even giving any error message if it is run from a pc where qt is not installed even though it has all the dlls in the same folder.
But if I install qt and try from the same folder the application will work without even setting the environment variable. In some questions i have seen people replied about adding the dlls and i have tried adding all the dlls specified by them. But nothing helped. Any body has an idea how to handle this.
Qt 5 introduced the use of some DLLs that are loaded at run-time (as opposed to launch-time). These DLLs can only be detected by Dependency Walker if you use the "profiling" feature, which is not on by default.
I'm assuming that you're using the precompiled package from the Qt Project website. The community found a silent dependency on libEGL.dll, and a less-silent dependency on qwindows.dll, which must be placed relative to your .exe with this folder structure:
app.exe
libEGL.dll
platforms\qwindows.dll
Also, see if you can find anything useful at http://doc-snapshot.qt-project.org/qt5-stable/qtdoc/deployment-windows.html
There is a bug report on bugreports.qt-project.org. It can help.
Related
I have built ffmpeg v3.2.4 shared libraries (dll) in windows 8.1, core i-7, using mingw-64 and msys2.
The reason was to update my old libraries that were used in my project.
The build was OK.
Also, my application has successfully linked with those dll's.
However, when I am running my app, I got a message program can't start because libiconv-2.dll is missing in your computer. I overcome this issue by adding --disable-iconv switch in configure before running make to build the ffmpeg libs from sources.
Then I got the same message with zlib dll missing. Then added --disable-zlib switch.
But then, I got libbz2-1.dll is missing when running the app. I don't know how to solve the last one, but, what am I missing here? Why didn't I need all these dll file in the old ffmpeg version (0.7.17) and now I do (latest ffmpeg (checked out tag n3.2.4)) ??
Thanks for the answers,
Aviv
I'm on windows 7 64bit, trying to run some software and I am getting an error indicating that I am missing qt5widgets.dll. I tried to find this dll from different websites but didn't have any luck. Where can I find the files to resolve this dependency ?
You should contact the person who gave you the application. The necessary libraries should have been included in the distribution.
Failing that, you may want to try here you will need to get the version that the application is expecting, and potentially match the compiler that was used to build the application.
You would expect the required dll's would come bundled with the application. This application is a QT application and the aforementioned dll's can also be found at QT5 official website.
Installed FreeImage through MacPorts. Everything looked to be OK, but when I builded my app and tried to launch on other computer where is no MacPorts and no FreeImage installed it says
dyld: Library not loaded: /opt/local/lib/libfreeimage.3.dylib
Referenced from: /Users/development/Library/Developer/Xcode/DerivedData/freeimage-dxsornyaxqlkyubqwsrlkgszvxhy/Build/Products/Debug/freeimage.app/Contents/MacOS/freeimage
Reason: image not found
Shouldn't it copy library files together with my project? I added them to my project's build phases "Copy files" list. They are being copied to my app's bundle. But when I try to link them, I get same error. I don't know why but app is still looking for library in /opt/local/lib. How can I fix it so that I could use FreeImage at my project and run it at any computer?
When you install through MacPorts the library is installed in /opt/local/lib, not in your project path. Even if you copy the whole project, the *dylib libraries won't be copied because they are usually in /opt/local/lib.
I believe you have two options here: install FreeImage in every computer that you want to run your application, or copy the libfreeimage.3.dylib to the same folder where your binnary is and, if both systems are similar, that should work. If the two computers are different in terms of operating system version, hardware architecture, etc... then probably the .dylib that you have won't be compatible for the other computer.
Another thing you might want to consider is to modify your DYLD_LIBRARY_PATH variable, which specifies the paths in which the OS will look for libraries when linking. See this answer for more information.
I have just completed my GTK#/Mono application and am preparing to build an installer. (I'm working in .NET Framework 3.5 and the Most recent stable Mono, 2.6.7, which installs Gtk 2.10.0) I would prefer to make the install as local as possible and not force people to go installing GTK# for .NET on their own. I looked at the installer for banshee (http://banshee.fm) to guide me, and I got almost all of the way there. Unfortunately, the PNG resources I had embedded in my application were not loading.
After an hour or so of intimacy with procmon (http://sysinternals.com), I find that the file libpixbufloader-png.dll isn't being loaded. It's being searched for in only one place: c:\program files\GtkSharp\2.12\lib\gtk-2.0\2.10.0\loaders. If I create just that folder tree and stick the file there, it works.
It seems slightly insane that GTK#/GTK would only look in a single hardcoded location for this file -- not even in the folder the application is in. Can someone tell me if a) this is indeed expected behavior, and b) if there's anything I can do about it, short of having my installer make this path itself? I know I can also just spawn out the GTK# installer, but I was hoping to keep all the Mono/GTK stuff local to my installation, to avoid later confusions over versions, etc.
I think your installer needs to run this at the end:
C:\Program Files\GtkSharp\2.12\bin\gdk-pixbuf-query-loaders.exe
See the Wix for the official Gtk# installer here:
https://github.com/mono/gtk-sharp/blob/gtk-sharp-2-12-branch/msi/unmanaged/unmanaged.wxs
You don't have to call the .exe mentioned my jpobst, because you can enter relative paths into the gdk-pixbuf.loaders config file (btw as you see the paths are not hard coded).
I have built a .dll under WinXP that claims it can't find DWMAPI.DLL when it's loaded. The problem is that this DLL is a Vista DLL, and this a known issue for XP users that have IE7 installed. The recommendation is to uninstall IE7 or repair the .NET Framework via Add/Remove programs. I did the repair, and nothing changed. I'm not about to uninstall IE7 since there must be a better solution that's not the equivalent of "reinstall windows".
I've read bad things about people who attempted to uninstall IE7, so I'm reluctant to go that route.
I am using C++ under Visual Studio 2003 (7.1). I don't see an option where I may have forced delay loading at application launch. I just used default settings when I created the DLL project. I did just now find an interesting option, Linker->Input->Delay Loaded DLLs, so I put DWMAPI.DLL in there to force it to be delay-loaded. However, I get this when linking:
LINK : warning LNK4199: /DELAYLOAD:dwmapi.dll ignored; no imports found from dwmapi.dll
.. and it of course didn't change a thing when trying to load my DLL. For the heck of it, I added the whole tree of DLLs that lead to DWMAPI.DLL, and I get the same message. (For the record, it's foundation.dll->shell32.dll->shdocvw.dll->mshtml.dll->ieframe.dll->dwmapi.dll .)
To be more specific about what I'm doing, I am writing a Maya plugin and get the always-helpful text in the script editor:
// Error: Unable to dynamically load : D:/blahblahblah/mydll.mll
The specified module could not be found.
//
// Error: The operation completed successfully.
//
// Error: The operation completed successfully.
(mydll) //
I used Dependency Walker to initially track down the problem, and that's what lead me to DWMAPI.DLL. These are the message depends gives me, and DWMAPI.DLL is the only thing that has a yellow question mark next to it:
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.
Gerald is right. Maya is, in fact, using a different PATH than the Dependency Walker. My plug-in loads another DLL (for image processing) that lives in the Maya plug-ins directory and depends found it with no problem, but Maya didn't. I had to add ";plug-ins" to the PATH in Maya.env.
Seeing as this problem wasn't related to DWMAPI.DLL after all, but DWMAPI is a common problem, I'll post the best link I found about the DWMAPI issue on Novell's website here. Basically, most programs will have this warning in depends.exe, but if there is a delay-load icon next to it, and you are sure that the program won't directly or indirectly call DWMAPI, then it's fine. The problem is elsewhere. If the delay-load icon isn't present, then you have to look at the /DELAY and /DELAYLOAD options in Visual Studio. The fact that depends gave me a "warning" and not an "error" was a clue to the fact that DWMAPI is not being loaded automatically.
Based on your updated problem, DWMAPI.dll is probably not your problem. Dependency walker will always give you that error whenever you are linking to mshtml as it always checks delay loaded DLLs.
At this point my best guess is that you have your project set to dynamically load the runtime libraries and the search path for DLLs is being changed by Maya. So it may be unable to find the MSVC runtime DLL(s). I haven't developed Maya plugins in a long time, but I've had that problem with other apps that have plugin DLLs recently.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.
Aside from that you can try fiddling with Dependency Walker to make it use the same search paths as Maya and see if you can come up with another dependency problem.
As a last resort you can launch Maya in a debugger and set a breakpoint on LoadLibrary and find out which library is not being loaded that way.
This is a tricky one. There's really 2 main ways you will get this error.
1) You have your project set to force delay loaded DLLs to load at application launch. DWMAPI.dll is a delay-loaded DLL and thus normally will not be loaded unless one of it's functions is called. That won't happen on XP unless you're trying to do it in your DLL. But it's possible to set a compiler option to force your app to load the delay loaded DLLs anyway. If you're doing that, don't.
2) It's often a false error that you will get from depends.exe when there is another problem. Run your DLL through dependency walker and see if there are any other dependency problems. If all else fails, try uninstalling IE7 and see if the problem persists. If it is a false error, after you install IE7 you will see the real error. You can install IE7 again afterwards.
I had exactly this problem.
Sneaky problem that took hours to solve.
Anyway. I compiled my managed C++ application on the release machine. Got complaints from customers that could not run it, worked like a charm on all of our machines.
It turned out that the release machine was automatically patched one night a month ago with the ATL vulnerability fix, and so was all other machines also, except one XP machine.
That particulare XP machine could not run the application either. Installed the ATL fix (see link below), and voilá, every thing worked just like before.
http://www.microsoft.com/downloads/details.aspx?familyid=766A6AF7-EC73-40FF-B072-9112BAB119C2&displaylang=en
So lesson learned, always check your intermediate manifests (found the in debug or release directory), that will tell you what version of the DLL that the program have been linked against.
Hope it helps anyone.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.