Jenkinks and MacOS application signing

After re-installing our MacOS building machine which we’re using for ORM Designer deploy, we started to getting following message:

./OrmDesigner2.app: User interaction is not allowed.

After short searching on the internet I found it’s required to click on “Always Allow” dialog…. which unfortunately we don’t have on the console ;-).

The trick is in the keychain unlock. For this purpose we can use following command:

security unlock-keychain -pPASSWORD ~/Library/Keychains/login.keychain

That’s all. After this command I’m able to sign my application from Jenkinks command line again.

External links

MacOS open file hander, app icon and other PLIST features

How to configure PLIST

This is how look ORM Designer plist file to correct setup file handler and application icon:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="1.0">
<dict>
  <key>CFBundleVersion</key>        <string>1.0</string>
  <key>CFBundlePackageType</key>    <string>APPL</string>
  <key>CFBundleExecutable</key>     <string>@EXECUTABLE@</string>
  <key>CFBundleIdentifier</key>     <string>com.orm-designer.OrmDesigner2</string>
  <key>CFBundleSignature</key>      <string>????</string>
  <key>CFBundleGetInfoString</key>  <string>ORM Designer2, Copyright 2012 Inventic s.r.o.</string>
  <key>CFBundleIconFile</key>       <string>@ICON@</string>
  <key>NOTE</key>                   <string>ORM Designer2 by Inventic Corporation</string>

  <key>CFBundleDocumentTypes</key>
  <array>
    <dict>
      <key>CFBundleTypeName</key>         <string>ORM Designer project file</string>
      <key>CFBundleTypeRole</key>         <string>Editor</string>
      <key>CFBundleTypeIconFile</key>     <string>@ICON@</string>
      <key>LSHandlerRank</key>            <string>Owner</string>
      <key>LSIsAppleDefaultForType</key>  <true/>

      <key>CFBundleTypeExtensions</key>
      <array>
        <string>ormdesigner</string>
        <string>ormdes</string>
        <string>ormdesigner2</string>
        <string>ormdes2</string>
      </array>
    </dict>
  </array>
</dict>
</plist>

Qt links:

Apple developer links:

Icon converting online tools

Very slow svn updates from Virtual Machines (VMWare)

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.

QWidget: Must construct a QApplication before a QPaintDevice

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.

export DYLD_PRINT_LIBRARIES=1 

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.

To turn off this debug output, use:

unset DYLD_PRINT_LIBRARIES

How to create .DEB package for Unix Debian-like systems

This guide isn’t complete. Create valid .DEB file is a much harder than I thought. So I will create .DEB file (and update this article) when I will have a more free time.

This is how now looks lintian result ;-( :

dev@user-virtual-machine:~/dev/Applications/AtomixDevelopment/DeployInfo/Ubuntu$ lintian ormdesigner.deb 
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/OrmDesigner2
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/OrmDesigner2
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libQtCore.so.4
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libQtGui.so.4
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_chrono.so
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_chrono.so
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_chrono.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_chrono.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_date_time.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_date_time.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_filesystem.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_filesystem.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_iostreams.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_iostreams.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_regex.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_regex.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_system.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_system.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libboost_thread.so.1.49.0
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libboost_thread.so.1.49.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libexslt.so.0
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libxml2.so.2
E: orm-designer: embedded-library usr/share/orm-designer/libs/libxml2.so.2: libxml2
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libxslt.so.1
E: orm-designer: arch-dependent-file-in-usr-share usr/share/orm-designer/libs/libyaml-cpp.so.0.2
E: orm-designer: unstripped-binary-or-object usr/share/orm-designer/libs/libyaml-cpp.so.0.2
W: orm-designer: unknown-control-file control~
E: orm-designer: control-file-has-bad-permissions postinst 0775 != 0755
E: orm-designer: control-file-has-bad-owner postinst dev/dev != root/root
W: orm-designer: unknown-control-file postinst~
E: orm-designer: control-file-has-bad-permissions postrm 0775 != 0755
E: orm-designer: control-file-has-bad-owner postrm dev/dev != root/root
W: orm-designer: unknown-control-file postrm~
E: orm-designer: no-copyright-file
W: orm-designer: extended-description-line-too-long
W: orm-designer: package-relation-with-self breaks: orm-designer (<< 2.0.1)
E: orm-designer: wrong-file-owner-uid-or-gid usr/ 1001/1001
W: orm-designer: non-standard-dir-perm usr/ 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/ 1001/1001
W: orm-designer: non-standard-dir-perm usr/share/ 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/ 1001/1001
W: orm-designer: non-standard-dir-perm usr/share/orm-designer/ 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/OrmDesigner2 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/OrmDesigner2 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/ 1001/1001
W: orm-designer: non-standard-dir-perm usr/share/orm-designer/libs/ 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libQtCore.so.4 1001/1001
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libQtGui.so.4 1001/1001
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_chrono.so 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_chrono.so 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_chrono.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_chrono.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_date_time.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_date_time.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_filesystem.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_filesystem.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_iostreams.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_iostreams.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_regex.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_regex.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_system.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_system.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libboost_thread.so.1.49.0 1001/1001
W: orm-designer: non-standard-executable-perm usr/share/orm-designer/libs/libboost_thread.so.1.49.0 0775 != 0755
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libexslt.so.0 1001/1001
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libxml2.so.2 1001/1001
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libxslt.so.1 1001/1001
E: orm-designer: wrong-file-owner-uid-or-gid usr/share/orm-designer/libs/libyaml-cpp.so.0.2 1001/1001
W: orm-designer: maintainer-script-ignores-errors postinst
W: orm-designer: maintainer-script-ignores-errors postrm~
W: orm-designer: maintainer-script-ignores-errors postrm
W: orm-designer: maintainer-script-ignores-errors postinst~
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_chrono.so 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_chrono.so.1.49.0 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_date_time.so.1.49.0 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_filesystem.so.1.49.0 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_iostreams.so.1.49.0 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_regex.so.1.49.0 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_system.so.1.49.0 0775
E: orm-designer: shlib-with-executable-bit usr/share/orm-designer/libs/libboost_thread.so.1.49.0 0775

Prerequisities

sudo apt-get install build-essential autoconf automake autotools-dev dh-make debhelper devscripts fakeroot xutils lintian pbuilder

Commands

#creates .deb file
dpkg -b ormdesigner-2.0.1 ormdesigner.deb

#validate .deb file
lintian ormdesigner

How to add screenshot to .DEB file

http://screenshots.debian.net/
http://stackoverflow.com/questions/4776624/how-to-create-deb-package-with-screenshot-for-ubuntu

Errors

E: orm-designer: wrong-file-owner-uid-or-gid usr/ 1001/1001
...

External links

http://www.ibm.com/developerworks/linux/library/l-debpkg/index.html
How to create DEB from source files
How to remove some litian errors

How to create nice MacOS DMG installer

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)

#! /bin/bash

TEMPLATE_DMG=atomix-development-template.dmg
VOLUME_NAME="Atomix Development"
APPLICATION_FILE_NAME="AtomixDevelopment.app"

if [ "$1" = "create-template" ]
then
  echo Create DMG template
  mkdir template
  cd template
  mkdir $APPLICATION_FILE_NAME
  touch $APPLICATION_FILE_NAME/fake
  ln -s /Applications/ Applications
  cd ..
  rm $TEMPLATE_DMG
  rm $TEMPLATE_DMG.bz2
  hdiutil create -fs HFSX -layout SPUD -size 100m "$TEMPLATE_DMG" -srcfolder template -format UDRW -volname "$VOLUME_NAME" -quiet
  rm -rf template
elif [ "$1" = "zip-template" ]
then
  echo Zipping DMG template
  bzip2 "$TEMPLATE_DMG"
elif [ "$1" = "create-dmg" ]
then
  echo Creating DMG file from template and data

  #unzip template
  rm $TEMPLATE_DMG
  bunzip2 -k $TEMPLATE_DMG.bz2

  #create pack path and attach DMG
  PACK_PATH=`pwd`/dmg-pack
  mkdir $PACK_PATH
  hdiutil attach "$TEMPLATE_DMG" -noautoopen -quiet -mountpoint "$PACK_PATH"

  #copy new content to DMG
  cp -r "$2" "$PACK_PATH"
  rm $PACK_PATH/$APPLICATION_FILE_NAME/fake

  #detach DMG, remove mount path
  hdiutil detach "$PACK_PATH" -force -quiet
  rm -rf $PACK_PATH

  #compress DMG
  hdiutil convert -format UDZO -o tmp-packer-output.dmg "$TEMPLATE_DMG" -imagekey zlib-level=9
  rm ./$TEMPLATE_DMG
  mv ./tmp-packer-output.dmg $TEMPLATE_DMG

  #rm $TEMPLATE_DMG
else
  echo Missing parameter
  echo "create-dmg [create|zip-template|create-dmg Path/Application.app]"
fi

So, it looks like that DMG file for ORM Designer2 is ready ๐Ÿ˜‰

Another tools to create DMG package

External links

http://codevarium.gameka.com.br/how-to-create-your-own-beautiful-dmg-files/
http://el-tramo.be/guides/fancy-dmg/
http://stackoverflow.com/questions/96882/how-do-i-create-a-nice-looking-dmg-for-mac-os-x-using-command-line-tools
http://stackoverflow.com/questions/8680132/creating-nice-dmg-installer-for-mac-os-x
http://stackoverflow.com/questions/2104364/how-to-install-a-qt-application-on-a-customers-system

How to deploy Qt application on MacOS – part II

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:

macdeployqt Application.app

That’s all ;-). This command should do all the hard work for you. But in some cases it didn’t.

ERROR: no file at "/usr/lib/libboost_iostreams.dylib"
ERROR: no file at "/usr/lib/libboost_filesystem.dylib"
ERROR: no file at "/usr/lib/libboost_system.dylib"
ERROR: no file at "/usr/lib/libboost_thread.dylib"
ERROR: no file at "/usr/lib/libboost_date_time.dylib"
ERROR: no file at "/usr/lib/libboost_regex.dylib"
ERROR: no file at "/usr/lib/libboost_chrono.dylib"
ERROR: no file at "/usr/lib/libyaml-cpp.0.2.dylib"

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:

otool -L libboost_regex.dylib
libboost_regex.dylib:
	libboost_regex.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

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!)

  install_name_tool -id "$SHL_PATH/boost/lib/libboost_chrono.dylib" $SHL_PATH/boost/lib/libboost_chrono.dylib
  install_name_tool -id "$SHL_PATH/boost/lib/libboost_date_time.dylib" $SHL_PATH/boost/lib/libboost_date_time.dylib
  ...
  install_name_tool -change "libboost_system.dylib" "$SHL_PATH/boost/lib/libboost_system.dylib" $SHL_PATH/boost/lib/libboost_chrono.dylib
  install_name_tool -change "libboost_system.dylib" "$SHL_PATH/boost/lib/libboost_system.dylib" $SHL_PATH/boost/lib/libboost_filesystem.dylib

So, now when we have updated all libraries, we can try to create application bundle again

macdeployqt AtomixDevelopment.app/

And if we did everything correctly, now we should have a working app ;-).

Troubleshooting

In some cases you can get error “Permission defined”, “Bad file descriptor” or other similar errors when using macdeployqt.

ERROR: "install_name_tool: can't open input file: OrmDesigner2.app/Contents/Frameworks//libssl.1.0.0.dylib for writing (Permission denied)
install_name_tool: can't lseek to offset: 0 in file: OrmDesigner2.app/Contents/Frameworks//libssl.1.0.0.dylib for writing (Bad file descriptor)
install_name_tool: can't write new headers in file: OrmDesigner2.app/Contents/Frameworks//libssl.1.0.0.dylib (Bad file descriptor)
install_name_tool: can't close written on input file: OrmDesigner2.app/Contents/Frameworks//libssl.1.0.0.dylib (Bad file descriptor)

The reason is insufficient permissions for modifying copied libraries. Simple execute

sudo macdeployqt

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.

DMG file

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 ;-).

Notes

  • 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:

  1. Use sudo and execute macdeployqt with root permissions
  2. Update external libraries permissions to rw, so also copies will have a correct permissions
  3. 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

Frameworks/liblzma.5.dylib is not writable (Permission denied)

Orinal library is located in path:

/usr/local/Cellar/xz/5.0.4/lib

How to deploy Qt application on MacOS – part I

As I wrote yesterday, I found the way how to proceed deployment on the Linux system. Today I have to manage it the same on the MacOS systems.

Note: the simplest way is introduced in the second part of this article.

The first usefull command for tracking dependencies between your application and other shared libraries is otool:

#path to executable, not .App directory!
otool -L Application.app/Contents/MacOS/AppExecutable

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:

cd Application.app/Contents/MacOS
otool -L AppExecutable

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.

$user otool -L AtomixDevelopment

AtomixDevelopment:
	libboost_iostreams.dylib (compatibility version 0.0.0, current version 0.0.0)
	libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/User/dev/SharedLibraries/libxml/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
	/Users/User/dev/SharedLibraries/libxslt/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0)
	/Users/User/dev/SharedLibraries/libxslt/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.15.0)

And Library:

User$ otool -L libxml2.2.dylib
libxml2.2.dylib:
	/Users/User/dev/SharedLibraries/libxml/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

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.

install_name_tool -id "@loader_path/libxml2.2.dylib" libxml2.2.dylib
otool -L libxml2.2.dylib
libxml2.2.dylib:
	@loader_path/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

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.

install_name_tool -change "/Users/User/dev/ExternalLibraries/../SharedLibraries/libxml/lib/libxml2.2.dylib" "@loader_path/libxml2.2.dylib" AtomixDevelopment

otool -L AtomixDevelopment
AtomixDevelopment:
	libboost_iostreams.dylib (compatibility version 0.0.0, current version 0.0.0)
	libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0)
        ...

So, now we have changed also path in our executable. And now we need to do all these steps for all libraries….. ;-).

 

Notes

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.

External links

Why is compiled Linux executable so large?

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 --strip-unneeded /path/to/application

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.