这个错误很遗憾地试图告诉你的是 lib clang 认为它的 @rpath 是你的应用程序包的根目录，但它不是。
就在前几天，我艰难地想通了这一点。
这个很难（硬。
您必须使用构建阶段设置对 libclang.a 做一些疯狂的事情。
在目标的构建阶段中，您需要添加一些运行脚本阶段。
一个是这样的：
echo "warning: OTOOL BEGIN1";
pwd;
otool -L ${SRCROOT}/Clangwrap/ClangAndLLVM/lib/libclang.dylib;
echo "Warning: OTOOL END1";
这只是做一些事情。
首先，它用日志很好地把事情夹在中间，看看发生了什么。
第二个是它实际上只是在复制后确认您的库的路径。 （是的，您应该将其复制到您的项目中以保持理智。）
otool 就是这样做的。
SRCROOT 是您项目的根目录，之后的任何内容都是您在 Finder 中项目文件夹中到您要使用的库的相对路径。
再一次，这只是证实了它就是您认为的位置。
好的，下一步。这是真正的笨蛋。
echo "BEGIN install_name_tool";
install_name_tool -id @executable_path/../Frameworks/libclang.dylib ${SRCROOT}/Clangwrap/ClangAndLLVM/lib/libclang.dylib;
echo "END install_name_tool";
这会运行晦涩的命令行工具 install_name_tool 并用于设置 lib 认为它位于应用程序包中的路径。如果不这样做，lib 会认为它在其他路径中。你将把这条路径设置成你想要的样子。在 Mac 应用程序中，我使用了包中的 Frameworks 文件夹，因此我将其设置为这样。 install_name_tool 的第一个参数是您的应用程序包中 lib 所在的相对路径。第二个参数是 lib 当前在您的项目中的位置，以便 install_name_tool 可以设置其可执行路径。
这从字面上修改了一些库，因此它是可加载的。 libs 必须知道自己的加载路径。
请注意，第一步只是您自己的理智可选。
第二步是必需的，两者都应该发生在编译源构建阶段之前。
单击并拖动以将它们向上移动。
现在是最后一步。添加一个新的复制文件阶段，这将在您的构建阶段中保持最后。
将目标设置为与 install_name_tool 的第一个参数相同，这样您就知道您的相对路径已设置，这就是您要放置 lib 的位置。
我使用了框架。
现在将文件添加到此构建阶段，对于 iPhone，添加 libclang.a（我认为您不能在 iOS 上使用 libclang.dylib）
注意，您看到我使用 libclang.dylib，那是因为我在 Mac 应用程序项目中执行此操作。几乎任何事情都应该是相同的过程。
这不是一个容易或容易发现的过程，我从几个博客和文档中拼凑而成。