For debugging purposes it's a good idea to keep .pdb files also for release version of your libraries. Unfortunately in default configuration Qt library doesn't generate .pdb files. It's a not big deal, create .pdb files for release version it's pretty simple.
1) Add compilation flags to .pro file
The easiest way how to create pdb files is pass /Zi switch to compiler and /Debug to linker.
2) Solution via mkspec
As pointed out in this QtProject article, another way is to edit mkspec so any future compilations will have this option turned on. It's necessary to modify correct mkspec file, for example
and add following lines (it should be sufficient to add only /Zi and /Debug switch):
We encounter several problems when we tried to deploy our new version of ORM Designer - Skipper to our new web site skipper18.com. Although new Skipper installer is very simmilar to ORM Designer installer, when downloading this exe-file from the new site we are getting this error:
The problem is somewhere in chrome/IE when evaluating downloaded file. Probably combination of new site, new executable and new name of product is the problem.
To fix this issue, we decided to sign-in installer and application executable by **Code-signing certificate.** There are a lot of certificate providers and the costs are very different. A lot of providers are selling these certificate for around $500/year. Fortunately it's possible to found certificates also for $75 - $95/year. The cheapest one is from tucows.com but based on the site and additional tools I decided for ksoftware.net, The price $95/year isn't so different but they offer also command line and GUI signing tool for their certificates called kSign.
Fill your company details, pay with paypal and wait until someone from Comodo will contact you with additional details. It's necessary to have the same contact information on the domain registration as on certificate registration. It is also necessary to have company registered in one of publicly available lists with the same company information as on certificate registration.
Next step is a validation through phone call. It is a quick call when you confirm registration info through the call in order to verify your phone number. Phone call is the last necessary step and then you receive email with certificate:
Signing of the application and installer is pretty easy. K-Software offers two applications for this purposes. The first one is with GUI, second one is command line based. Both applications need only few parameters like where the certificate is stored, certificate password, application description, link and executable location:
Command line application is executed through following command:
And that's all. Now if you checked your executable through properties in Windows explorer, you see that your application is correctly signed:
Today my Visual Studio 2010 started to execute my application super slowly. When I tried to execute my application (without any changes in source-code) the delay between "Start Debugging" and application start was about one minute.
I know that too many breakpoints or breakpoints in templates could caused this, but I don't see any breakpoint in my Breakpoints window.
But as I have found that the problem was really caused by breakpoints. In some special cases - when you're using some external tools to modified your project file (.sln/.vcxproj) - breakpoints can disappear and begin to make a trouble (I'm using Qt qmake to update my project based on .pro files.)
The solution is pretty easy. Use **Delete All Breakpoins** from Debug menu:
[caption id="" align="aligncenter" width="637"] The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL32.dll[/caption]
Today we received report from one of our customers about problem with our ORM Designer on WindowsXP - 32bit. Our latest version returns following error:
The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL32.dll
**The problem is that GetTickCount64 doesn't exists in XP system**.
It's necessary to compile your application (and any library which uses GetTickCount64) with correct **WINVER** and **_WIN32_WINNT **defines value. List of WINVER values for all Windows version can be found here.
You can define these values in your resource.h file:
#define WINVER 0x0501
#define _WIN32_WINNT 0x0501
or add it to a project property -> C/C++ -> Preprocessor -> Preprocessor Definitions:
If you want to define these values automatically in Qt project, add following lines to your .pro file:
#Windows XP compatability
DEFINES += "WINVER=0x0501"
DEFINES += "_WIN32_WINNT=0x0501"
Also the issue may be the result of Aggressive Link State Power Management (ALPM) on the PCI-Express bus negotiating a lower power state for the link between the controller and disk when there is no activity. When ALPM works, disk requests are queued, the serial link revived, and the queued requests are sent to the relevant disk; this requires a disk that supports ALPM.
Integration of Google breakpad on any platform is really challenge. I didn't figure out how to do it by using recommended ways. So I did it my way ;-)
Create your own Qt project
As first thing I did when integrating Qt and Breakpad is creation of my own .pri file. I manually add all required files from Breakpad one-by-one, starting with src/platform/exception_handler continuing with all files included in previous ones. The complete .pri file you will find at end of this post.
After that I created simple CCrashHandler (inspired by qt-breakpad project) class which register exception handler. It's necessary to implement this handler for each platform separately because each platform have different parameters in google_breakpad::ExceptionHandler() constructor. CrashHandler source code you can find also at end of this post.
Do almost all steps like on Linux integration. There is one exception, because you can't compile Breakpad tools using linux-like configure&make. You have to build these tools with XCode.
Compile google_breakpad/src/tools/mac/dump_syms/dump_syms.xcodeproj with XCode
Before I managed to successfully compile dump_syms in XCode, I have to update Architectures Debug/Release to 64-bit Intel and BaseSDK to "Latest Mac OS X". I also fix all issues displayed in the left part of XCode window.
Next step is change compilation type from Debug to Release. After a short searching I found a way in "Schema->Edit schema->Build configuration".
To be honest, I was not sure what I did, but it worked ;-). Maybe there is some easier way how to compile dump_syms in xcode, but I don't know how. This was my first contact with XCode ;-).
The application is compiled to path "/Users/User/Library/Developer/Xcode/DerivedData/dump_syms-bjvr/Build/Products/Release/dump_syms". Now copy dump_syms to safe location from where you will use it.
The most amazing thing I found about dump_syms is their platform independence. If you correctly extract symbol file on each platform and store it in one location, you can analyze any crashdump on one location. No matter what is source platform, you will analyze .dmp file by using **minidump_stackwalk ./crash.dmp ./symbols**.
How to include CrashHandler directly to your project
This is what I get when I follow all includes from **.h** and **.cpp** files starting with exception_handler.h for all platforms. With small modification you can include it to your project and your application will be fully breakpad-able ;-).
And this is the minimal implementation of your new CrashHandler. My ownd crash handler is much more sophisticate to perform reporting, sending crash dump etc. But for purposes of this article this is what you need (And also I don't want to share my whole know-how here ;-)))
This short post will show you how to resolve following error during Qt compilation on 64-bit windows:
This error is caused by bug in **QMAKE_HOST** variable used in WebCore.pro file. This variable is tested to determine destination platform (x86 or x64).
This variable contains x86 value also on 64-bit builds instead of x86_64 value. This value is tested on the following line in a WebCore.pro file:
If you want to fix this error, simply replace **QMAKE_HOST** by **QMAKE_TARGET** variable. Updated line should look like this:
After this update all required asm defines are correctly included and build of WebKit will be successful.
Update for this error
In newer versions of Qt there is already applied fix the error with QMAKE_HOST / QMAKE_TARGET, but also there is a new problem ;-(.
The Problem is in the following "if" definition:
When you compile your project for MSVC 2010, .asm file isn't included. It's necessary to add win32-msvc2010 to this definition. So updated WebCore.pro for Qt 4.8 will look like this:
Next problem solution
Next problem which I found during compilation is wrongly set QMAKE_TARGET.arg. For unspecified reason, when I compile 64bit library in 64bit system in 64bit VS command line, this variable has value x86 instead of x86_64.
The problem is in the qmake project.cpp file. QMAKE trying to determine 64/32 bit version based on the %PATH% configuration. Qmake search for VS-PATH\bin\amd64 of \bin\x86_amd64 string. Unfortunately there is a bug in concating searched string. This is how looks original project.cpp file at line 3177:
The problem is, that VCINSTALLDIR contains \ at the end of the string, and then we append \ again. So, result is:
Now, QMake correctly determine 32/64 bit compilation and then correctly include PaintHooks.asm and your Qt WebCore will be sucesfully compiled.
Quick post about problem which I already solved, but think that could be handy for someone else.
I have following code:
When compiling under Visual studio, everything is ok. But when try the same code snippet under g++, have following error:
This is because compiler doesn’t known FindByType method, because T2 is templated argument. The solution which I found is in adding keyword template before FindByType method name. So updated source code will look like this:
After this update, code will be compiled correctly under both compilers.
Sometimes happened that two DLL libraries wants to be loaded in same address. These DLL libraries can be found in "Modules" window with small red exclamation mark. When you need to change this address, you have to update your linker settings adding the /BASE: parameter.
Compilation under Windows is possible only using MinGW and with few modifications in TENG code (because there is few glitch which didn't meet c++ standards). If you want more information or updated TENG version, please let me know.
Today I found out that Windows version of Git doesn't support Unicode character in file names. After some time spent by searching on google, I found updated version of msysgit with Unicode support. This version is available here: http://tmurakam.org/git/. Thank you Takuya Murakami!
Lots of open source libraries (like libiconv, libintl, ...) doesn't have MSVC project files or makefiles. Only supported way how to compile given library under Window is using MinGW and MSYS compiler tools.
Here is step-by-step guide how to download, install and compile libraries using MinGW.
Run downloaded executable. As install directory leave C:\MinGW. It's recommended not to change this path. On component screen select C compiler, C++compiler, MSYS Basic System and MinGW Developer Toolkit.
After that select next,next,next, finish ;-). After that installer downloads all necessary files. This could take a few minutes.
When installation is done, as next step is necessary to setup PATH variable to c:\MinGW. Installer doesn't modify it automatically. (more info about modifying PATH variable) .
Installing additional gcc compiler and make support
These two packages isn't listed in available components. If you wish to install it, use mingw-get-inst. In c:\MinGW\bin directory run following commands:
Step three compiling
Compiling from windows shell
Launch cmd tool, go to directory with source code and use g++.
Compiling from MinGW console
Launching MinGW console
Laung MinGW from startmenu or msys.bat from %INSTALL_PATH%\MinGW\msys\1.0\msys.bat.
Command line for generating Visual studio project file from Qt .pro file.
Missing moc_*.cpp file
When some of moc file isn't properly generated and getting following error:
Select corresponding .h file (for moc_xxx.cpp select xxx.h) in a project tree and select **Compile** from context menu. If the file is marked as "up-to-date", try to change something in this file and repeat a compilation. If in the output window will be "up-to-date" again, you found a problem.
Use context menu on the corresponding .h file, select properties and edit "Configuration properties |Custom build steps|General|Outputs" to any value (add some char to the end of value), confirm change by Ok button and then return value back to original (remove added char). After that, compilation on correspond file will be successfully performed.