BeiweiHuang 2013-03-01
引用自:http://www.cnblogs.com/E7868A/archive/2012/12/02/2798225.html
Qt编写的应用发布到用户手里,同时也要把Qt库一起打包给用户。方法有很多。
简单是因为静态编译的Qt库会随着应用一起发布,麻烦是我们必须自己编译静态的Qt。而且,很多情况下我们不仅是要使用Qt,还有很多其它的库,如果每一个都静态编译,我们的执行文件就太巨大了。所以简单的应用,静态编译可能是好的,但是,比较大的项目,这种方法就不推荐了。
Mac中的GUI应用必须以Bundle的形式运行,所谓Bundle,是一个以".app"结尾命名的文件夹,系统自动识别它为一个应用包,应用所有的东西(执行文件、链接的动态库、资源文件等等)都在里面了,打开应用直接"open myApp.app"就可以了,安装的时候直接把Bundle拖到Finder里就行了。卸载的时候直接把Bundle删除就行了。多让人省心。
Bundle的结构如下图:(从Qt文档里借来的)
我们如果要随着我们的应用一起发布Qt库,比较合理的就是把所有需要的Qt库都复制到Frameworks目录中。
使用otool可以查看一个应用都链接了哪些动态库
$ otool -L myApp.app/Contents/MacOS/myApp myApp.app/Contents/MacOS/myApp: libqxmpp.0.dylib (compatibility version 0.7.0, current version 0.7.4) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.9.0, current version 4.9.3) QtXml.framework/Versions/4/QtXml (compatibility version 4.8.0, current version 4.8.3) QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.3) QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.3) QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.3) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
我们用了QtWebKit、QtXml、QtCore、QtGui、QtNetwork,然后挨个Copy吧。
$ cp -R /path/to/Qt/lib/QtCore.framework myApp.app/Contents/Frameworks ...... ......
真的悲惨到到自己手工去复制?当然不是,我们都是懒人啊,Qt自身带了一个macdepolyqt的神器,一切就变得简单了。
$ macdeployqt myApp.app ERROR: no file at "/usr/lib/libqxmpp.0.dylib"
qxmpp是我们用的一个三方库,并不在/usr/lib下,找不到并不奇怪,怎么才能让macdeployqt找到这个三方库呢?
Mac下是用DYLD_LIBRARY_PATH来寻找动态库的,类似于Linux下的LD_LIBRARY_PATH。otool -L输出的信息,其实是保存在编译好的可执行文件里的。libqxmpp.0.dylib没有指定绝对路径,系统会到DYLD_LIBRARY_PATH中去寻找它,macdepolyqt并不理会DYLD_LIBRARY_PATH,所以,我们只好将libqxmpp.0.dylib这一条修改成它的绝对路径,让macdeployqt可以找到它。
install_name_tool -change "libqxmpp.0.dylib" "/opt/library/qxmpp/lib/libqxmpp.0.dylib" myApp.app/Contents/MacOS/myApp
如此以后就没问题了
$ macdeployqt fytclient.app $ otool -L myApp.app/Contents/MacOS/myApp myApp.app/Contents/MacOS/myApp: @executable_path/../Frameworks/libqxmpp.0.dylib (compatibility version 0.7.0, current version 0.7.4) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) @executable_path/../Frameworks/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.9.0, current version 4.9.3) @executable_path/../Frameworks/QtXml.framework/Versions/4/QtXml (compatibility version 4.8.0, current version 4.8.3) @executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.3) @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.3) @executable_path/../Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.3) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
这时候再看otool的结果,qxmpp以及Qt的动态库都指向了Bundle里Frameworks目录下了。@executable_path顾名思义就是应用的执行目录,也就是myApp.app/Contents/MacOS
另外,install_name_tool命令也可以写到qt .pro file中,类似:
http://www.qtforum.org/article/14932/qmake-post-link-in-pro.html
BS += -L../myapp/3rd/msgpack-0.5.4/src/.libs -lmsgpack -L../myapp/3rd/libev-4.11/.libs -lev macx{ QMAKE_CFLAGS_X86_64 += -mmacosx-version-min=10.7 QMAKE_CXXFLAGS_X86_64 = $$QMAKE_CFLAGS_X86_64 msgpacklib.path = Contents/Frameworks msgpacklib.files = ../myapp/3rd/msgpack-0.5.4/src/.libs/libmsgpack.3.dylib evlib.path = Contents/Frameworks evlib.files = ../myapp/3rd/libev-4.11/.libs/libev.4.dylib QMAKE_BUNDLE_DATA += msgpacklib evlib QMAKE_POST_LINK = install_name_tool -change /usr/local/lib/libmsgpack.3.dylib \ @executable_path/../Frameworks/libmsgpack.3.dylib \ myapp.app/Contents/MacOs/myapp & \ install_name_tool -change /usr/local/lib/libev.4.dylib \ @executable_path/../Frameworks/libev.4.dylib \ myapp.app/Contents/MacOs/myapp }
INSTALL_NAME_TOOL(1) INSTALL_NAME_TOOL(1)
NAME
install_name_tool - change dynamic shared library install names
SYNOPSIS
install_name_tool [-change old new ] ... [-rpath old new ] ... [-add_rpath new ] ... [-delete_rpath new ] ... [-id
name] file
DESCRIPTION
Install_name_tool changes the dynamic shared library install names and or adds, changes or deletes the rpaths
recorded in a Mach-O binary. For this tool to work when the install names or rpaths are larger the binary should
be built with the ld(1) -headerpad_max_install_names option.
-change old new
Changes the dependent shared library install name old to new in the specified Mach-O binary. More than one
of these options can be specified. If the Mach-O binary does not contain the old install name in a speci-
fied -change option the option is ignored.
-id name
Changes the shared library identification name of a dynamic shared library to name. If the Mach-O binary
is not a dynamic shared library and the -id option is specified it is ignored.
-rpath old new
Changes the rpath path name old to new in the specified Mach-O binary. More than one of these options can
be specified. If the Mach-O binary does not contain the old rpath path name in a specified -rpath it is an
error.
-add_rpath new
Adds the rpath path name new in the specified Mach-O binary. More than one of these options can be speci-
fied. If the Mach-O binary already contains the new rpath path name specified in -add_rpath it is an
error.
-delete_rpath old
deletes the rpath path name old in the specified Mach-O binary. More than one of these options can be
specified. If the Mach-O binary does not contains the old rpath path name specified in -delete_rpath it is
an error.