This error can be caused by many things but I know about one more which I didn't find anywhere else ;-).
In case you compile and deploy your app by using qtmacdeploy and sign your application immediately, everything will probably works fine. The problem occurs, when you need to copy your application to different location (for example during dmg building). In such cases, this error can occur:
Althought codesign is executed as always, singing isn't successful:
The problem is, that during the copy it's necessary to keep all symbolic links inside frameworks. Without this, singing will fail.
To be more specific, problem occurs only in very specific circumstances. It's in situation, when application is compiled as console-app and it's compiled on Mac OS X version older than 10.9:
and when you're using QEventLoop::exec in mode processing all events except user events (QEventLoop::ExcludeUserInputEvents):
In this situation, application hangs-up. When the application is compiled with GUI mode or when application is compiled on Linux/Windows (no matter if gui or console), everything works find. To fix this problem, it's necessary to implement hack similar to this (simplified version):
When .plist file is manually updated on MacOS 10.9+, changes are not directly applied to plist cache. This means that these changes aren't visible to executed application (even if you run it after plist change).
It's necessary to tell plist change to reload this settings. There are two ways how to do it. First one is simpler but doesn't work if you completely remove .plist file:
Second method is much more efficient, but requires to completely kill plist cache. This cache is immediately executed again and during this launch all plist files are scanned and loaded again:
[caption id="" align="aligncenter" width="435"] MacOS unidentified developer in ORM Designer[/caption]
To solve this error message it's necessary to do following steps:
Register in Apple developer program and pay $99 per year
Download and install developer certificate
Sign whole application
1) Register on Developer.apple.com
You need to create registration here: https://developer.apple.com/. It's necessary to fill info about contact person and company. After that, your registration will be reviewed by apple team and if everything will be OK, your registration will be approved.
Now you need to install this certificate to your developer machine. Simply double-click on certificate and let system to import it. You can check that certificate is imported in **Go->Utilities->Keychain Access->login. **Now search for "Developer ID Application: XXXX"
**Note: **In my case when I transfer certificate to several developer machines I need to migrate also other Apple certificates. Without that my certificate wasn't a valid.
**3) Sign your application**
Now you need to sign your application including all plugins and frameworks inside app bundle. **After you sing your app, you can't do any changes in the bundle.** So as first run your deploy as usual and as **last step **do app singing.
For ORM Designer sign script looks like this:
4) Test it!
As last step it's necessary to test that sign process was successful. As first you can try following command line to validate it:
Now when you checked that App is correctly signed, it's time to try it on clean computer where no security policy changes was made. Upload your app and execute it.
If you don't see annoying screen "Can't execute application from unidentified developer", **you win** ;-).
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 ;-)))
Today I encounter this error after applying **macdeployqt** to my application. There is a lot of questions about this topic on google but not very answers.
The most important thing is setup following variable.
Using this you will se which libraries are loaded during execution of your application. The interesting thing is, that I see loading a libraries from their original directories instead of Application.app. But when I temporary moved these libraries from their location, libraries begin to load from then bundle location.
The reason for my "QWidget: Must construct a QApplication before a QPaintDevice" was executing an older version of QTitanRibbon from shared libraries path instead of the newest one compiled directly to /usr/lib.
The second reason for this issue was caused by another path in "export DYLD_LIBRARY_PATH". It seems that application search for libraries first in DYLD_LIBRARY_PATH and after in paths from their inner records.
In this article I will show how to create DMG installer in reusable way. The most of things and ideas presented here are ideas from several articles mentioned on the end of this article.
1) As first step we need to create our DMG template with link to Applications.
2) Next we have to modify the visual representation of DMG file.
3) Next we store created DMG as template
4) Now mount copied template as directory, fill DMG with real files
5) Detach mounted DMG, pack DMG
6) Distribute app ;-)
More detailed info about all these steps you will find in articles mentioned below. Here is a short script I wrote for three-phase deploying (1) create template, 2) pack template, 3)fill template with real data and compress it)
In first part of this article I introduced a manual way how to deploy MacOS application. Because doing all these stuff manually was a lot of hand work, Qt introduced small tool called **macdeployqt**.
This utility looks very good, but also have some drawbacks. As first I will show you how utility works:
That's all ;-). This command should do all the hard work for you. But in some cases it didn't.
The problem is that libraries mentioned in the previous list doesn't has included absolute path. If you inspecit this library, you will se this:
And this is the problem. Inner path in library is only filename without full path, so when we link library with our executable, our executable also has only relative path. And when macdeployqt try to find this library, automatically try to search in /usr/lib.
One possible solution is copy libraries to /usr/lib. Second solution is update paths in libraries to absolute paths. The third way is fix library linker to include full paths in libraries.
I found out that the simplies way how to fix it is call install_name_tool after library compilation and fix the path (don't forget to update library paths inside other library paths!)
So, now when we have updated all libraries, we can try to create application bundle again
And if we did everything correctly, now we should have a working app ;-).
In some cases you can get error "Permission defined", "Bad file descriptor" or other similar errors when using macdeployqt.
The reason is insufficient permissions for modifying copied libraries. Simple execute
and everything should work ok. Another workaround for this issue is using newer version of Qt. I figured out that on MacOS I wrongly use Qt 4.7.4. When I correct this to version Qt 4.8.2 this issue was solved.
If you want to create simply DMG file, simply call macdeployqt with param --dmg. But this dmg doesn't look so good:
This will need more investigation how to make DMG files nicer ;-).
Everytime you run macdeployqt run it on clean folder. The best way is to call rm -rf Application, compile app and than run macdeployqt
Notes to bug in macdeployqt
The problem is caused by invalid permissions. Copied libraries have the same permissions like in the source location. There are three different solutions:
Use sudo and execute macdeployqt with root permissions
Update external libraries permissions to rw, so also copies will have a correct permissions
Update macdeployqt script. In file shared.cpp on line 91 is method copyFilePrintStatus. Here is a necessary to update copied files permissions to correct rw
In my case the problem was in file liblzma.5.dylib
The first usefull command for tracking dependencies between your application and other shared libraries is otool:
Now we can see paths to our libraries. The bad news is that MacOS doesn't have any -RPATH and $ORIGIN. The good news is utility install_name_tool and variable @executable_path which works similar like $ORIGIN. Note: For newer versions of MacOS there are more variables like @executable_path. On version 10.4 was introduced @loader_path and on version 10.5 apple introduce @rpath variable.
The step-by-step solution
As first step it's necessary to upload all dependent libraries directly to the Application.app/Contents/MacOS/. For list all required files use otool:
When we have copied all libraries, we need to change paths **for** and **in** all libraries.
Here is example how to set libxml2 library. As first step we will check how is library referred.
When we checked libxml2.2.dylib library with otool, we can see that library has hardocoded our development path. This isn't good ;-). So we now change this value to path relative to the executable and again verify this inner path.
As you can see, now is path (first line) set up to reffer @loader_path/libxml2.2.dylib. It's correct now. As second step we have to update path in our executable, because also there is path hardcoded to our library repository.
So, now we have changed also path in our executable. And now we need to do all these steps for all libraries..... ;-).
To follow the MacOS application convention it's better to place libraries to folder Application.app/Contents/Frameworks. Here is a directory schema for Qt example application plugAndPaint.
If your application using some externals dynamic libraries (called .dylib in MacOs system), you have to provide all these libraries. The simplest way is to provide these libraries into the Application.app directory.
Find out which libraries are used
Qt provide really useful tool called **"otool"** which serves to lots of purpose. One of them is to detect which shared libraries are required by our application. For this purpose otool has parameter -L. The usage is following:
Output could looks like this:
Output from "otool" is simmilar to linux tool "ldd".
The Mac Deployment Tool
Because manual copying and configuring all shared libraries to our application could be difficult, Qt have deployment tool which do all work for us. Tool is called "macdeployqt" and can be found in /Developer/Tools/Qt/macdeployqt.
**Note:** Every time when you call macdeployqt tool, project have to be build from scratch. But is sufficient when whole result directory is removed and linked again:
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.