I have a lot of virtual machines used for my everyday development. It's very frustrating the SVN update speed if you have several externals in your main SVN source.
Today when I wait for some compilation start searching if there is anything what could improve SVN speed. After searching a lot of articles about faster network, better server hdd,... I found article with mention how SVN client communicate with server (intensively ;-) ). But without any clue how to improve it.
So I start searching how SVN client communiacte from within VMWare machines to server. I noticed that VMWare default network settings is NAT: Used to share the host's IP address:
So I start trying other network methods and this is the result:
When I use "Custom: Specific virtual network" and choose "VMnet0 Bridged", my svn update is about ten times faster than on NAT settings!!. I also tried first option "Bridged:..." but this doesn't work for me.
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.
Today I encountered another issue when compiling my Qt application http://www.orm-designer.com/ under Linux. The size of final executable was about 400MB.
The first thought was that there is some static libraries compiled to application. But the problem was elsewhere.
Unlike to Windows compilation where linker creates .exe and .pdb file, linux linker creates only one final file. So this file includes also lot of additional symbols useful for debugging and post-mortem bugs finding. But it is not so usefull for distribution your application. To strip all these symbols, use following command
Strip command have a lot of switches, but after a short testing it seems that the results are the same. Maybe I'm doing something wrong or simply my executable doesn't contain any additional infos for stripping.