i also have the same problem with VMware 7.0.1 build-227600 and a clean windows XP
Added after 1 25 minutes:
we found the problem, will report back when we know the solution!
i also have the same problem with VMware 7.0.1 build-227600 and a clean windows XP
Added after 1 25 minutes:
we found the problem, will report back when we know the solution!
Last edited by janton; 9th August 2011 at 13:59.
Ok, just found out that plugins require visual studio redistributable package installed or crt folder inside the imageformats directory. I think this is why most people don't experience problems with plugins, but users are not obligated to have vcredist installed.
Not every one. Some apps statically link those libs. For my project I simply include crt folder. It would be strange to install vcredist for a small tool.
Nothing prevents you from doing the same (including statically linking the image plugins). Just remember that if you statically link the application, you include a static version of the C runtime as well, as regardless of linking mode the C runtime is still required.
Is it possible to link qt plugins statically when I use compiled binaries? I tried to build and got this error:
Perhaps, compiled version allows dynamic linking only.Qt Code:
error LNK2019: unresolved external symbol "class QObject * __cdecl qt_plugin_instance_qjpeg(void)" (?qt_plugin_instance_qjpeg@@YAPAVQObject@@XZ) referenced in function "public: __thiscall StaticqjpegPluginInstance::StaticqjpegPluginInstance(void)" (??0StaticqjpegPluginInstance@@QAE@XZ)To copy to clipboard, switch view to plain text mode
For linking statically you need statically linked versions of the libraries you use (including Qt and the C runtime of your compiler).
Is it possible to place plugin dlls to the folder other than imageformats? Namely I'd like to have those dlls nearby my exe-file, so I don't have to copy crt libraries two times.
I tried QCoreApplication::addLibraryPath(qApp->applicationDirPath()), but it didn't work.
Not without rebuilding Qt. But you shouldn't need two crt sets, one is enough, provided they are the same crt file.
One crt folder is needed for exe file, another one is needed for imageformats directory. If I could place plugins to the same folder as exe then I could use only one crt folder.
as i told yesterday, image plugins don't work without vcredist. if installing vcredist is not an option it is possible to place crt libraries inside imageformats folder - then it works. another crt folder is needed for the project itself, because it was built with msvc 2008. yes, both crt folders are absolutely the same and i am trying to avoid duplication, but plugins don't work if i place them to the same directory as exe file.
My question is very simple -- is it the same file (I'm not asking about the file name)? I assume you know what dll files are and how they work so you surely know that if this is the same file (or even exporting the same symbols), only one copy of the file will be open and the other will be totally ignored.
I'd like to clear up what file are you talking about? If crt dlls, then yes, they are absolutely the same. I copied Microsoft.VC90.CRT folder into imageformats directory. It is stupid, but this is the only way I got images work in the browser on clean machine (without vcredist).
I tried it different:
1) I have crt folder nearby my exe, but not inside the imageformats folder:
As you can see, doesn't work.
2) I have content of crt folder nearby my exe, but not inside imageformats folder:
Also doesn't work.
3) I have content of crt folder nearby my exe, also I have all plugin dlls there, so everything is in the same directory:
Doesn't work either.
4) I have crt folder nearby my exe, and the copy of it inside imageformats folder.
Now it works.
Please use the attachment feature of the forum to attach images instead of using 3rd party sites.
You have something seriously screwed up since as far as I know by default the Windows dynamic loader doesn't look into any subdirectories for dll files. Apparently the application manifest states the file should be found there. Check the manifest for your application and make sure Qt and your application are compiled using the same version of the compiler.
Also if you built the program from within Visual Studio, please try building it from the command line using qmake && nmake and see if the problem persists.
As you can see there is no manifest file for the application at all, and the application I tested was imageviewer. It is a sample qt app, I didn't even build it, just copied exe file to my virtual machine. But generally, yes, I use Microsoft Visual Studio 2008 SP1 and I already had problems with manifest and libraries, but this is not the case, I think.
As far as I know the manifest is embedded into the binary file. You need to extract it and have a look. How to do that is out of scope of this forum though, I'm sure you'll find something using your favourite search engine. It's likely you tweaked some configuration in visual studio (or your build system) during your previous struggles with manifests which somehow influences your current setup. Did you try building from the command line as asked?
I didn't build it. I downloaded Qt binaries here (only it was 4.7.2 at that time), then installed it, found imageviewer sample and copied exe file to a clean XP on my virtual machine. If somebody tweaked visual studio configuration, that was not me, but Qt people who created those binaries. As long as the test application is qt sample I post it to Qt forum. I guess Microsoft people won't help me much with Qt demo.
If something is done wrong in Qt binaries, I hope it to be fixed. Otherwise, I'd like to know how to run those samples, because as you can see it is not that easy to run when Visual C++ Redistributable is not installed.
Bookmarks