Tag: deploy

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

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

• Article about MacOS deployment
• http://doc.qt.nokia.com/4.7-snapshot/deployment-mac.html