macOS 10.14及以下系统curl_mime_init符号缺失问题如何解决？

问题核心原因 #

你本地升级curl后问题仍然存在，是因为：

• 你的.framework在Xcode中默认链接的是系统路径/usr/lib/libcurl.4.dylib，你通过第三方工具升级的curl默认安装在/usr/local/或/opt/homebrew等非系统默认路径下，Xcode不会主动链接该版本的库，所以你的.framework仍然依赖系统自带的旧版本libcurl
• macOS 10.14及更低版本预装的libcurl最高版本为7.54.0，确实没有curl_mime_init这个7.56.0版本才新增的接口，这是系统预装库的版本限制导致的，属于系统特性问题。

可行解决方案 #

方案1：将libcurl静态编译进你的.framework（最推荐） #

• 下载对应版本的libcurl源码，编译时指定最小支持的macOS版本为你需要兼容的最低系统版本，编译出静态库libcurl.a
• 在你的.framework编译配置中，将链接选项从动态链接系统libcurl，改为链接你自行编译的静态libcurl，所有curl相关符号会直接打包进你的.framework，完全不依赖系统自带的libcurl，不会再出现符号找不到的问题
  注意：编译静态libcurl时，一定要把MACOSX_DEPLOYMENT_TARGET参数设置为和你的.framework的最低兼容macOS版本一致，否则静态库本身也会存在低版本系统兼容问题

方案2：做多版本兼容的双实现 #

• 上传逻辑保留两套实现：运行时通过curl_version_info()接口获取当前系统libcurl版本号，当版本>=7.56.0时使用curl_mime_init新接口，版本低于7.56.0时使用旧版curl_formadd接口实现文件上传，该接口在7.54.0版本中已存在，可正常调用
• 该方案无需自行编译libcurl，但需要维护两套上传逻辑，旧接口在新系统中仅提示废弃不影响运行。

方案3：打包高版本动态libcurl随产品分发 #

• 编译高版本libcurl动态库，修改动态库的install name为@rpath路径，将该动态库和你的.framework一起打包进宿主程序的Frameworks目录下
• 该方案需要额外处理动态库签名、rpath路径配置，流程比静态编译繁琐，不优先推荐。

内容的提问来源于stack exchange，提问作者Lance