最近被安排来搞定android、ios、mac、windows下的webrtc、ffmpeg和x264的编译问题。

除了由于webrtc配置工程的问题在windows下我自己的搭建环境无法使用，最终求助于之前使用的虚拟机环境以外，android下的webrtc都比较顺利，同样也是编译anroid环境的和windows环境的ffmpeg，相对来说也是比较顺畅（虽然还是出现了一些坎坷）。

但在Mac环境下编译webrtc、ffmpeg和x264就没有那么幸运了。简直就是人间地狱，首先说明一下，这个Mac机原先是有其他开发者在上面编译成功过这三个工程的，到我之后就开始出现了一大堆问题（当然也有可能我用的是用户新帐号的缘故）。

人间地狱的开始

• 先说一说编译webrtc遇到的坑爹问题。由于webrtc编译环境我们只输出静态库，并不输出一个framework或者app，所以并不需要关心太多app层面的问题（如证书相关）。虽知道在webrtc的gyp检查项目中会对证书冲突做检查，由于机器中存在多个证书，导致gyp阶段无法生成正确的编译配置参数。导致折腾了一周，最后才发现和证书有关。虽然这个问题和gyp有一定的关系，但也只是我对mac上编译和交叉编译的被坑的起点。

• 接着是x264和ffmpeg编译时，由于给我的工程之前都是能够成功编译的，现如今拿过来，除了Mac平台可以通过以外，真机和模拟器都不行。折腾来折腾去几天，最后发现是clang去找依赖的时候找错了，找了mac的依赖环境，而不是去找iphoneos的依赖，然后怎么调都没用。很是坑爹，就拿网上的现成脚本来跑也是不行。

最后去查config.log，发现一堆错误，其中ffmpeg的错误还有一个叫做gas-preprocessor.pl的执行错误，由于是通过git直接从网上拿下来的脚本，在没有任何修改的情况下，通过sftp发到mac里面，给了执行权限之后通过命令行直接执行一点问题都没有，但通过configure执行时就一直报没有权限的错，怎么也想不明白；后来试着用curl拿文件，居然通了。当时我就估计如果不是字符集的问题，就是权限标记位的问题。

接着再继续修改关于依赖的问题，仅仅一个交叉编译工具clang，居然在不同的工程里面对同一个路径参数能够出现多种不同的行为，后来还特意看了一下clang是不是GNU开源社区的代码，通过–version看到的内容如下：

Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

可见这个坑是苹果自己的。可能是由于命令行的长度的不同，导致解析命令行的bug？或者其他什么坑爹问题？反正我是不知道了，近几年开始苹果的产品也不见得有多少优势了，正在被一点点拉小差距。如果不是为了混口饭吃，苹果的任何产品我真的不想去碰！