Xcode虽然已经用过很久了,但是很少接触Mac App的开发,尤其是对于Mac App的动态链接库用法更是知之甚少(大部分时间都是在做iOS开发而iOS又不支持动态链接库⊙﹏⊙b汗),果然在研究FMOD Studio的跨平台音效库时遇到了问题…先是在win32下写了一段测试代码,配合Studio工具做出的bank完成了基本加载、播放等基本逻辑,准备上Mac平台试验一下,结果一通忙活include和lib后,编译链接没问题了,停掉虾米的推荐准备听听Mac版的声音效果如何,结果一运行程序就崩溃了,看了下日志输出:
dyld: Library not loaded: @rpath/libfmodL.dylib
Referenced from: /Users/wzkres/Library/Developer/Xcode/DerivedData/CCTechDemo-gdcppdyfmrhlhzhidvykxyjrcvwo/Build/Products/Debug/CCTechDemo Mac.app/Contents/MacOS/CCTechDemo Mac
Reason: image not found
感觉有点类似win32下的没找到动态链接库的dll…不过既然是没见过的提示,还是搜索学习一下吧。
看来这个@rpath是个新鲜东西,于是上bing搜索一下(最近苦逼啊,google产品被全面封杀,不得已改外事问微软了…),找到了一篇关于@rpath和其它几个同类path的介绍(貌似也是转载的,没G懒得找原文链接了):@executable path, @load path and @rpath – http://www.cppblog.com/lauer3912/archive/2012/04/18/171814.html,略读了一下,感觉有点win32下working path的意思,又想到Apple系统的应用.app其实是包含了执行文件,资源文件等乱起八糟的文件夹这点来,看来也是要指定什么类似的路径吧,于是第一想到的是和include路径接近的library search paths,看了一下,由于导入fmod的2个dylib,这个路径被自动加入了两个dylib的路径,不过看来是Xcode对带空格文件夹路径的处理不太到位,自动加入的路径变成了这个样子:
这个问题在开发iOS加入framework搜索路径时也遇到过,修改对了再套在 ” ” 里就可以了,本以为这样问题就可以解决了,结果重新编译运行时还是提示同样的错误,又回头看了一遍那篇“解说”,发现这样一句:
- the down side: you now have to pass additional linker flags when building the host application (eg.
-rpath @executable_path/../Frameworks
or/Library/Frameworks
; note that specifying both will cause the dynamic linker to try looking in both locations)
回到Xcode的build settings里仔细找了一下,果然发现了在Linking部分有个叫Runpath Search Paths的设置项,看来日志里的@rpath应该就是这个了,把library search paths里改过的fmod的两个路径原封不动的复制过来,再次编译运行程序,错误修正,调用代码正确执行!
PS:查找资料的时候也看到了一些别的解决方法,比如这里的:解决 “dyld: Library not loaded: ” 错误 – http://blog.csdn.net/ani_di/article/details/7078743,还有提到可以将dylib一起copy进.app中等,由于目前还只是简单测试一下,并没有考虑到实际app发布问题,所以这些还是有待日后研究吧:-D。
博主友情提示:
如您在评论中需要提及如QQ号、电子邮件地址或其他隐私敏感信息,欢迎使用>>博主专用加密工具v3<<处理后发布,原文只有博主可以看到。