I wanted to write c++ desktop application with fine UI, so I did it in QT Creator.
Then I decided to add some UI features, and I moved to QML(QT Quick Application).
I installed QML Desktop Components according to here instructions, used import Qt.labs.components 0.1 and it worked well.but now I have to deploy my application, and I noticed that the application runs only on Debug mode, and not on Release mode. I checked, and saw that I have just the styleplugind.dll, and not the styleplugin.dll. Shortly, I have only the debug dll, and not the release one. I installed the components again,for release, and I really got the styleplugin.dll. but when I'm running my application(I remembered adding CONFIG+=release to my .pro file),I'm getting this error:
loaded for module "Qt.labs.components": The plugin 'C:/QtSDK/Desktop/Qt/4.7.4/mingw/imports/Qt/labs/components/plugin/styleplugin.dll' uses incompatible Qt library. Expected build key "Windows mingw release full-config", got "Windows mingw debug full-config"
import Qt.labs.components 0.1
^
I don't understand why I'm getting that: I have the right .dll file, and everything seems okay.
(BTW, I'm on Windows7)
What should I do??
The problem is, as the error output states, that your styleplugin.dll is still build against an incompatible Qt build (debug, expected is release).
Related
we made one application on Visual Studio 2008 , it about to release. but now we are getting the crash while launching the application . could you please any give a suggestion how do i debug on this particular issue
You can run the Release build in the debugger, too. Turn on debug-info settings in both the compiler and linker tabs (I think that was not the default in vs2008 and there were two distinct places to set) but don't change any optimization options or other setting.
Then launch the program from the debugger. If the resulting EXE shows the crash when run normally but not when started via the debugger, there are more things to make the situations work the same (and that shows clues as to what is wrong, too). So let us know if that still doesn't reproduce.
There could be a lot of reasons for your application's Release is crashing.
Did you link proper Release libraries with your application in Visual Studio project configuration ?
Check your code for some missing Release specific code.
My best guess is you are not linking to proper libraries for the Release version of your application.
Also, one reason could be that your application may be trying to load some file that may not exist. This happens with me sometimes when my Release build of application does not find file that it needs (Eg: OpenGL application trying to load a shader file that is missing); and you don't check for errors.
I managed to compile VTK example (http://www.vtk.org/Wiki/VTK/Examples/Cxx/PolyData/Curvatures) in MSVS 2010 but when I tried to run it, it stopped. Does anyone know the cause? I can run other VTK examples successfully but not this one.
From the comments, the problem is caused by using Release .dlls in a Debug application. Remember that the Release heap is not compatible to the Debug heap. Which means any allocations in the Release heap can not be freed in the Debug heap or vise versa. As a result of this it is not generally safe to mix Debug and Release in the same application.
Now in the case of VTK (since I have used this on many machines and have built this 100s of times using Visual Studio over the last 5+ years) my recommendations are to turn off the building of shared libraries with vtk. And avoid the use the INSTALL target with for VTK, ITK, GDCM or any CMake based library that names its release libraries the same as its debug libraries. Instead use BUILD_ALL for all configurations you will need in your application. Then when you need to configure your application to use CMake I point VTK_DIR to the root directory of the folder where I built VTK and CMake will then correctly use the Debug libraries in my Debug application, Release libraries in my Release application..
I have had quite the experience trying to compile wxWidgets on Windows for x64. After a nightmare setting up Visual C++ 2008 express to compile x64 apps, I opened the wx.sln file. (I'm using wxWidgets 2.9.0, by the way.) I picked the Release configuration and set x64 as the platform. When I hit build, I get a slew of errors saying that wx/setup.h is missing. It would seem like the file is not being created. The real mystery is that the above steps work perfectly for wxWidgets 2.8.10. Any idea why this does not work?
Ensure that you have the file include/wx/msw/setup.h (in particular, it wouldn't be there if you checked sources out of svn). Other than that also check that you use vc9 versions of the project files just to be sure that you don't run into some import problems. With these projects all the necessary setup.h under lib/vc_lib (or vc_dll) directory should be created automatically by custom build steps in the projects.
I have installed the Netbeans 6.7 IDE with Java ME included, but cannot create a Mobile Application project from the Java ME category. When I select the project type the wizard stops at "Finding Feature" with the message:
Not all requested modules can be enabled:
[StandardModule:org.netbeans.modules.mobility.end2end.kig jarFile:C:\Program Files\NetBeans 6.7\mobility8\modules\org-netbeans-modules-mobility-end2end-kit.jar.
I am attempting to run this on Vista Home Premium. I have tried to run the IDE as Administrator with no luck.
I am at a loss for where to go next as I cannot seem to find any information regarding this issue. Even if you don't have the solution any insight into this error message would be helpful.
I am unable so far to get the project running via the Netbeans IDE install. I have, for the time being, installed the Java ME SDK which includes a very stripped down version of the Netbeans IDE for mobile development.
I originally had some issues starting the SDK as well on Vista. The IDE reported that it could not connect to the device manager on localhost. After some searching I found this link: Java ME SDK Startup Problem which suggests changing the hosts file localhost entry from IPv6 to IPv4. The fix worked perfectly and I can now compile and run code in the emulator.
This is not an optimal solution as the SDK does not include the visual design tools, however I am able to get a basic project going in the mean time.
I have given up on the 6.7 version and have instead located and installed 6.5.1. This previous version has been working just fine and seems to do everything I need.
I ran into the exact same error today while installing NB 6.8 beta. To resolve it we need to install two plugins:
Java Web Applications (as mentioned by Ali above) and
Sun Java System Web Server 7.0
Note that these two are part of the Category called "Java Web and EE" hence the confusion that we need to install Glassfish App Server. But we need these two plugins because they are required for debugging using breakpoints in emulator. Netbeans runs a web server when we do breakpoint based debugging.
Also note that the Java Web applications needs SOAP Web Services and JavaScript Debugger plugins to run and so these plugins are also installed when you try to install it.
You also need to install "Java Web Applications" plugin.
Tools->Plugins->Available Plugins
If the module is present, you should try unzipping it to check its content makes sense.
You should also be able to rebuild it from Netbeans sources.
You can also try to figure out why this happens by debugging the module loader inside Netbeans from its sources, using another IDE, presumably the latest version of Netbeans you can find without the issue.
If the module is missing, you might want to get the missing jar file from an installation of a previous version of Netbeans, see if it is compatible.
6.5.1 isn't missing any module.
back in version 5.5, the mobility module had to be downloaded and installed separately from the main IDE.
If you want to consider using Eclipse for developing your J2ME app...I've written a post related to that some time ago: here.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.